Introduction
FIELDNOTES has a correct visitor test, but its local release script can continue after a failed test and can publish a different package. Your task is to connect the decision to the actual delivery.
This fresh environment includes the completed visitor checks from the first lab and an unchanged live website. You will repair a short Bash pipeline, reject a bad input, publish a good one and show that later draft edits do not change the saved package. The same Workstation, Live Website and Candidate Preview tabs are ready. This is a local training pipeline, not GitHub Actions or a production security boundary.
Make Failure Stop the Release
In this step, you will make one candidate argument flow through testing and publication. Begin in Live Website. Open the exhibition, Plan your visit, and the visitor download. The current entrance is East gate. Return home with FIELDNOTES.
Switch to Workstation. cat prints the supplied pipeline:
cat pipeline.sh
The initial script runs a check, then tries to publish the fixed packages/candidate.tar.gz. Separate command lines continue even when the earlier command fails. The supplied publisher independently refuses an untested package; you must also make the pipeline return failure and pass the intended input through both stages.
Bash stores the first argument in $1. candidate="$1" saves it in a variable. "$candidate" expands that value as one argument, even when its path contains spaces. && runs the next command only when the preceding one exits with status zero. Zero means success; nonzero means failure. The last executed command determines this small script's result.
Use the here-document method from the first lab to replace the full script. The final BASH ends the literal block:
cat > pipeline.sh <<'BASH'
#!/bin/bash
candidate="$1"
python3 tools.py check "$candidate" &&
python3 tools.py publish "$candidate"
BASH
#!/bin/bash identifies the interpreter. You will run it explicitly with bash, so no executable permission change is needed. Both commands receive exactly the same package argument. Do not add || true, remove checks, or replace the argument with a fixed good package.
Test a bad candidate; this failure is intentional:
bash pipeline.sh packages/wrong.tar.gz
Expect FAIL: Wrong visitor guide content with no Published line. Immediately inspect the status: $? is the previous command's exit status and echo prints it. Run this separately, directly after the pipeline:
echo $?
Expect 1. Another command between these two would replace the status. In Live Website, reload and follow the visit and download links: the healthy baseline remains available. A rejected release must leave service working.
If you see a Bash syntax error, reread the saved file and restore the shown recipe. A broken script is not evidence of a working rejection gate. The next step proves that it can also accept a valid input.
Publish the Package You Tested
In this step, you will let a valid candidate reach the live website and distinguish saved package bytes from an editable working copy. Start in Workstation.
The supplied packages/candidate.tar.gz was built from drafts/ during preparation. The pipeline must use that saved package, not rebuild from whatever happens to be in drafts later.
First check the candidate explicitly:
python3 tools.py check packages/candidate.tar.gz
It prints a passing check and an identifier for the frozen package. Now simulate an ordinary developer edit after packaging. > replaces just this draft text file; the quoted text is printed by echo:
echo 'UNREVIEWED DRAFT: use the West gate' > drafts/downloads/guide.txt
Confirm that the draft really changed:
cat drafts/downloads/guide.txt
It prints UNREVIEWED DRAFT: use the West gate. This is an intentional draft-only edit. Do not edit or rebuild the saved package.
Run the corrected pipeline on the saved candidate:
bash pipeline.sh packages/candidate.tar.gz
Expect PASS: visitor checks. Frozen package ... followed by Published frozen package ..., with the same identifier. The runner tests a frozen copy and publishes those exact bytes; it refuses a package whose bytes have no successful check. The identifier is supporting evidence, not a replacement for checking the actual site.
Switch to Live Website, return home with FIELDNOTES and reload. Open Explore the exhibition, Plan your visit and Download visitor guide. The page and download both say East gate despite the unreviewed draft edit. Also open Step-free route and Download access guide; the Garden ramp is preserved. Check that the illustration and page styling remain intact.
Switch to Workstation. curl sends an HTTP request; -sS hides progress but shows connection errors. 127.0.0.1 means this lab environment and 8081 is the live server's port. These requests belong in Workstation, not your computer's terminal:
curl -sS http://127.0.0.1:8081/downloads/guide.txt
The body starts FIELDNOTES Visitor Guide and includes Entrance: East gate. The public site therefore uses the saved package, not the changed draft. If it shows draft text, inspect which input your pipeline publishes; rerun the corrected pipeline on the supplied unchanged candidate.
Finally exercise rejection again:
bash pipeline.sh packages/missing.tar.gz
Expect the intentional 404 failure and no publication. In Live Website, reload and repeat the visit download; the accepted candidate remains usable. The pipeline has now shown both decisions. This exercise protects a static website's local release path; it does not implement access control, signatures, hosted CI or database migration rollback.
Summary
You used conditional execution to stop bad releases, passed one package through both stages, and published its exact tested contents despite a later draft edit. The visitor and access journeys remain available.
