Einführung
FIELDNOTES hat einen korrekten Besuchertest. Das lokale Veröffentlichungsskript kann jedoch nach einem Fehler weiterlaufen und ein anderes Paket veröffentlichen. Deine Aufgabe ist es, die Entscheidung mit der tatsächlichen Lieferung zu verbinden.
Diese neue Umgebung enthält die fertigen Besuchertests aus dem ersten Lab und die unveränderte Website. Du reparierst einen kurzen Bash-Ablauf, lehnst eine schlechte Eingabe ab, veröffentlichst eine gute und zeigst, dass spätere Entwurfsänderungen das gespeicherte Paket nicht verändern. Workstation, Live Website und Candidate Preview sind bereit. Dies ist eine lokale Lernpipeline, kein GitHub Actions und keine Sicherheitsgrenze für den Produktivbetrieb.
Bei Fehlern die Veröffentlichung stoppen
In diesem Schritt führst du dasselbe Kandidatenargument durch Prüfung und Veröffentlichung. Beginne in Live Website. Öffne Ausstellung, Plan your visit und Besucherdownload. Der aktuelle Eingang ist East gate. Kehre über FIELDNOTES zur Startseite zurück.
Wechsle zu Workstation. cat zeigt die bereitgestellte Pipeline:
cat pipeline.sh
Das ursprüngliche Skript prüft und versucht danach, das feste Paket packages/candidate.tar.gz zu veröffentlichen. Einzelne Befehlszeilen laufen weiter, auch wenn die vorige scheitert. Der Publisher verweigert ungeprüfte Pakete zusätzlich selbst; du musst dennoch einen Fehlerstatus der Pipeline sicherstellen und die gewünschte Eingabe an beide Stufen übergeben.
Bash speichert das erste Argument in $1. candidate="$1" weist es einer Variablen zu. "$candidate" erweitert ihren Wert zu einem einzigen Argument, auch bei Leerzeichen im Pfad. && führt den nächsten Befehl nur aus, wenn der vorige mit Status null endet. Null bedeutet Erfolg, ein anderer Wert Fehler. Der zuletzt ausgeführte Befehl bestimmt das Ergebnis dieses kurzen Skripts.
Ersetze das ganze Skript mit der Here-Dokument-Methode aus dem ersten Lab. Das abschließende BASH beendet den wörtlichen Block:
cat > pipeline.sh <<'BASH'
#!/bin/bash
candidate="$1"
python3 tools.py check "$candidate" &&
python3 tools.py publish "$candidate"
BASH
#!/bin/bash nennt den Interpreter. Du startest das Skript ausdrücklich mit bash; ausführbare Rechte sind daher nicht nötig. Beide Befehle erhalten genau dasselbe Paketargument. Füge kein || true hinzu, entferne keine Prüfungen und ersetze das Argument nicht durch ein festes gutes Paket.
Prüfe einen schlechten Kandidaten; dieser Fehler ist beabsichtigt:
bash pipeline.sh packages/wrong.tar.gz
Erwarte FAIL: Wrong visitor guide content ohne Published-Zeile. Frage sofort den Status ab: $? enthält den Status des vorigen Befehls und echo gibt ihn aus. Führe dies getrennt direkt nach der Pipeline aus:
echo $?
Erwarte 1. Ein weiterer Befehl dazwischen würde den Status ersetzen. Lade Live Website neu und folge Besuchs- und Downloadlinks: Die gesunde Ausgangsversion bleibt verfügbar. Eine abgelehnte Veröffentlichung muss den Dienst funktionsfähig lassen.
Bei einem Bash-Syntaxfehler lies die gespeicherte Datei erneut und stelle die gezeigte Fassung her. Ein kaputtes Skript beweist keine funktionierende Freigabeprüfung. Der nächste Schritt zeigt, dass es auch gültige Eingaben annimmt.
Das geprüfte Paket veröffentlichen
In diesem Schritt veröffentlichst du einen gültigen Kandidaten und unterscheidest gespeicherte Paketbytes von einer bearbeitbaren Arbeitskopie. Beginne in Workstation.
Das bereitgestellte packages/candidate.tar.gz wurde bei der Vorbereitung aus drafts/ gebaut. Die Pipeline muss dieses gespeicherte Paket verwenden und darf es nicht aus dem späteren Entwurfsstand neu erstellen.
Prüfe den Kandidaten zunächst ausdrücklich:
python3 tools.py check packages/candidate.tar.gz
Er zeigt einen erfolgreichen Test und die Kennung des eingefrorenen Pakets. Simuliere nun eine normale Bearbeitung nach dem Packen. > ersetzt nur diese Entwurfstextdatei; echo gibt den Text in Anführungszeichen aus:
echo 'UNREVIEWED DRAFT: use the West gate' > drafts/downloads/guide.txt
Prüfe, dass sich der Entwurf tatsächlich geändert hat:
cat drafts/downloads/guide.txt
Er zeigt UNREVIEWED DRAFT: use the West gate. Diese absichtliche Änderung betrifft nur den Entwurf. Bearbeite oder baue das gespeicherte Paket nicht neu.
Starte die korrigierte Pipeline mit dem gespeicherten Kandidaten:
bash pipeline.sh packages/candidate.tar.gz
Erwarte PASS: visitor checks. Frozen package ..., danach Published frozen package ... mit derselben Kennung. Der Runner prüft eine eingefrorene Kopie und veröffentlicht genau deren Bytes; Bytes ohne erfolgreichen Test werden abgelehnt. Die Kennung ist ein ergänzender Beleg, kein Ersatz für die Prüfung der echten Website.
Wechsle zu Live Website, kehre mit FIELDNOTES zur Startseite zurück und lade neu. Öffne Explore the exhibition, Plan your visit und Download visitor guide. Seite und Download nennen trotz ungeprüfter Entwurfsänderung East gate. Öffne auch Step-free route und Download access guide; Garden ramp bleibt erhalten. Achte auf vollständige Illustration und Gestaltung.
Wechsle zu Workstation. curl sendet eine HTTP-Anfrage; -sS blendet den Fortschritt aus, zeigt aber Verbindungsfehler. 127.0.0.1 ist diese Lab-Umgebung und 8081 der Port der veröffentlichten Website. Diese Anfragen gehören in Workstation, nicht in das Terminal deines Rechners:
curl -sS http://127.0.0.1:8081/downloads/guide.txt
Der Inhalt beginnt mit FIELDNOTES Visitor Guide und enthält Entrance: East gate. Die Website verwendet das gespeicherte Paket statt des geänderten Entwurfs. Siehst du Entwurfstext, prüfe die veröffentlichte Eingabe und starte die korrigierte Pipeline erneut mit dem unveränderten bereitgestellten Kandidaten.
Prüfe abschließend noch einmal die Ablehnung:
bash pipeline.sh packages/missing.tar.gz
Erwarte den beabsichtigten 404-Fehler ohne Veröffentlichung. Lade Live Website neu und wiederhole den Besucherdownload: Der akzeptierte Kandidat bleibt nutzbar. Die Pipeline hat nun beide Entscheidungen gezeigt. Diese Übung schützt die lokale Veröffentlichung einer statischen Website; sie implementiert keine Zugriffskontrolle, Signaturen, gehostete CI oder Rücknahme von Datenbankmigrationen.
Zusammenfassung
Du hast bedingte Ausführung zum Stoppen schlechter Veröffentlichungen verwendet, dasselbe Paket an beide Stufen übergeben und trotz späterer Entwurfsänderung seine exakt geprüften Inhalte veröffentlicht. Besucher- und barrierearme Wege bleiben verfügbar.
