Sorge dafür, dass die neueste Mitteilung sichtbar bleibt

Einführung

Pine & Path bereitet einen Gartenspaziergang vor. Ein Redakteur bittet um einen späteren Beginn; ein anderer ändert anschließend den Treffpunkt. Jenkins kann beide Mitteilungen vorbereiten und veröffentlichen, doch ein älterer Durchlauf, der auf Freigabe wartet, könnte die neuere Ankündigung überschreiben, nachdem sie die Besucher bereits erreicht hat.

Du beobachtest dieses Überschreiben und änderst dann die Pipeline so, dass ein neuer Durchlauf automatisch einen älteren wartenden Durchlauf ablöst. Dein Ergebnis ist eine tatsächliche Besuchermitteilung und ein herunterladbares Paket aus sieben Dateien, dessen Route, Zeitplan und Hinweise alle der neuesten Anforderung entsprechen.

Vorausgesetzt werden grundlegende Kenntnisse der Navigation auf Jenkins-Seiten und das Erkennen einer kurzen Declarative Pipeline. Parameter, Freigabepausen und die Nebenläufigkeitseinstellung werden hier erklärt. Jenkins, zwei Controller-Executors, die Mitteilungswerkzeuge und der lokale Notice Desk sind vorbereitet. Du installierst keine Software und schreibst nicht die Website. Beide Oberflächen laufen auf einer Übungs-VM; dies ist ein kontrollierter lokaler Veröffentlichungsdienst, keine produktive Bereitstellungsplattform. Die Dauer ist eine Schätzung des Autors, keine mit Anfängern gemessene Zeit.

Beobachte, wie eine späte Freigabe eine Mitteilung überschreibt

In diesem Schritt veröffentlichst du die neueste Mitteilung und beobachtest dann, wie ein älterer wartender Durchlauf sie überschreibt. Beginne in Notice Desk. Halte diese Oberfläche geöffnet; das Wechseln zwischen Oberflächen startet keinen Build neu und setzt die Mitteilung nicht zurück.

Untersuche den normalen Ablauf für Besucher

Die erste Veranstaltung ist der Gartenspaziergang. Wähle seinen Link View notice. Die bereitgestellte Mitteilung nennt 10:00 bei Community Gate als Beginn. Öffne Open the route und untersuche die drei Haltepunkte. Kehre mit der Browseraktion Back zur Mitteilung zurück. Öffne Read visitor notes, lies die Treffpunktanweisungen und verwende dann erneut Back. Schedule table ist eine CSV-Datei: eine einfache Tabelle, deren Felder durch Kommas getrennt sind. Notice details ist JSON: benannte Werte, die dieselbe Veranstaltung beschreiben. Preparation record gibt an, wie dieses Paket vorbereitet wurde. An dieser Stelle steht dort zutreffend PROVIDED BASELINE; die Einrichtung hat den Jenkins-Job nicht für dich ausgeführt.

Kehre mit der Browseraktion Back zur Startseite von Notice Desk zurück. Wähle Download notice pack für den Gartenspaziergang und speichere das ZIP-Archiv. Eine ZIP-Datei hält mehrere Dateien zusammen. Entpacke das gesamte Archiv mit dem Archivprogramm deines Computers in einen neuen Ordner und öffne dann dessen index.html. Behalte alle sieben benachbarten Dateien zusammen. Route, Stylesheet, Zeitplan, Hinweise, JSON-Datei und Vorbereitungsnachweis sind tatsächliche lokale Dateien; wenn du nur index.html verschiebst, funktionieren die Links zu den Nachbardateien nicht mehr. Dein Browser kann eine CSV-/Textdatei öffnen oder herunterladen; beides eignet sich zum Lesen der gespeicherten Bytes.

Kehre zur Startseite von Notice Desk zurück. Untersuche die separate Mitteilung Seed Swap und ihren Download. Sie beginnt um 11:00 bei Potting Shed und muss unverändert bleiben. Die kommenden Redakteursanforderungen betreffen nur den Gartenspaziergang.

Wähle Read the editor requests. Die frühere Anforderung verwendet den Wert UPDATE later-start: 10:30, weiterhin Community Gate. Die neueste Anforderung ist new-meeting-point: Behalte 10:30 bei, Treffpunkt Glasshouse Gate. Hier bedeutet „neueste“ die spätere Redakteursanforderung, nicht den Build, der zufällig zuletzt fertig wird.

Lies die vorbereitete Pipeline

Wechsle zu Jenkins. Öffne publish-walk-notice und dann Configure. Suche den Abschnitt Pipeline und seinen Editor Script. Dies ist eine Declarative Pipeline: Der äußere Block pipeline { ... } beschreibt die Arbeit, und zusammenpassende geschweifte Klammern gruppieren seine Einstellungen und Stages.

Der Job verwendet agent any, das auf einem verfügbaren vorbereiteten Node einen Executor und ein Arbeitsverzeichnis zuweist. Ein Executor ist ein Jenkins-Ausführungsplatz; ein Workspace ist das Arbeitsverzeichnis eines Durchlaufs. Dieser Übungscontroller hat zwei Executors, sodass sich zwei Durchläufe dieses Jobs überlappen können. Sie haben separate Arbeitsverzeichnisse, veröffentlichen aber in dieselbe Gartenmitteilung.

Der Block parameters definiert Werte, die für jeden Build gewählt werden. choice bietet die beiden Redakteursanforderungen als UPDATE an. booleanParam macht HOLD_FOR_REVIEW zu einem Kontrollkästchen: aktiviert bedeutet true, deaktiviert bedeutet false. params.HOLD_FOR_REVIEW liest den für diesen Durchlauf gewählten Wert. Eine Bedingung when führt ihre Stage nur aus, wenn der Ausdruck wahr ist.

Die drei Stages haben unterschiedliche Aufgaben:

• Prepare notice leert das Arbeitsverzeichnis des Durchlaufs mit deleteDir(), ruft mit sh das bereitgestellte Vorbereitungsprogramm auf und archiviert notice-pack.zip. archiveArtifacts bewahrt exakt diese Datei beim systemeigenen Build auf. fingerprint: true erfasst ihre Inhaltsidentität und den zugehörigen Build. Vorbereitung und Archivierung ändern die Besuchermitteilung nicht.
• Review notice verwendet input, um einen Durchlauf mit aktiviertem Kontrollkästchen vor der Veröffentlichung anzuhalten. Sein Link Proceed erlaubt die nächste Stage; Abort bricht diesen Durchlauf ab. Dies ist eine beabsichtigte Pause, kein Verbindungsfehler.
• Publish notice sendet das vorbereitete Paket an den lokalen Notice Desk. Der Block post { always { ... } } leert das Arbeitsverzeichnis beim Ende des Durchlaufs, auch bei einer Unterbrechung. Systemeigene archivierte Dateien bleiben nach der Workspace-Bereinigung verfügbar.

Die bereitgestellten Vorbereitungs- und Veröffentlichungsprogramme lesen die Parameter und das Archiv des tatsächlichen Builds. Behalte diese Programme, alle Stages, die Prüfbedingung für die Freigabe, das Fingerprinting und beide Bereinigungsoperationen bei. Im nächsten Schritt änderst du nur, wie überlappende Durchläufe behandelt werden. Lasse das Script vorerst unverändert. Wähle Save, um zum Job zurückzukehren.

Starte einen älteren Durchlauf und lasse ihn warten

Wähle auf der Jobseite publish-walk-notice den Eintrag Build with Parameters. Wähle later-start für UPDATE und aktiviere HOLD_FOR_REVIEW durch Klicken auf seine Beschriftung oder sein Kontrollkästchen. Wähle einmal Build.

Öffne den neu gestarteten Durchlauf in Build History; bei einem unveränderten Job ist dies #1. Öffne Console Output. Warte auf Release this selected notice? mit den Links Proceed und Abort. Lasse ihn warten. Die Konsole hat Vorbereitung und Archivierung bereits gemeldet. Die gemeinsame Besuchermitteilung des Jobs ist noch die Ausgangsversion, weil Publish notice nicht ausgeführt wurde.

Kehre über den Brotkrumenlink publish-walk-notice oben zur Jobseite zurück. Dies navigiert innerhalb von Jenkins; es unterscheidet sich vom Wechsel zur Oberfläche Notice Desk. Notiere die ältere Durchlaufnummer, damit du zu ihrer wartenden Konsole zurückkehren kannst.

Wähle erneut Build with Parameters. Wähle diesmal new-meeting-point und lasse HOLD_FOR_REVIEW deaktiviert. Wähle einmal Build. Öffne Console Output dieses neuen Durchlaufs und warte auf Finished: SUCCESS. Bei einem unveränderten Job ist dies #2.

Wechsle zu Notice Desk und lade die Startseite neu. Öffne die Gartenmitteilung: Jetzt sollten 10:30 und Glasshouse Gate erscheinen. Öffne ihre Route und Besucherhinweise und prüfe denselben Treffpunkt. Die neueste Redakteursanforderung ist tatsächlich veröffentlicht.

Setze den älteren Durchlauf fort

Wechsle zurück zu Jenkins. Kehre zum Job zurück, öffne den notierten älteren Durchlauf und seine Console Output und wähle dann dessen Link Proceed. Warte auf Finished: SUCCESS. Falls du eine veraltete Konsole geöffnet hast, lade die Konsole dieses Durchlaufs vor dem Wählen des Links neu; starte nicht einen weiteren Build, nur um eine Seite zu aktualisieren.

Wechsle zu Notice Desk, lade die Seite neu und untersuche die Gartenmitteilung erneut. Jetzt steht dort 10:30 bei Community Gate. Dies ist der erwartete Fehler: Der ältere Durchlauf wurde später fertig und überschrieb die neuere Anforderung. Beide Jenkins-Durchläufe waren erfolgreich, doch für die Besucher war nun wieder die überholte Mitteilung sichtbar.

Lade dieses aktuelle Paket in einen anderen Ordner herunter. Seine publication.txt nennt den älteren Jenkins-Durchlauf; Route, Zeitplan und Hinweise stimmen mit dieser älteren Anforderung überein. Kehre zu Jenkins zurück und öffne den Link Build Artifacts dieses älteren Builds, um seine systemeigene notice-pack.zip herunterzuladen. Notice Desk hat dieses tatsächlich vorbereitete Archiv ausgeliefert, statt stillschweigend eine andere Mitteilung zu erzeugen.

Falls ein Durchlauf unerwartet wartet, untersuche seine gewählten Parameters und die Konsole. Du kannst an seiner Eingabeaufforderung Abort wählen, um einen versehentlich wartenden Durchlauf abzubrechen, und dann die beabsichtigten Parameter erneut starten. Behalte den gesamten Buildverlauf bei. Eine Fehlermeldung vor der Aufforderung unterscheidet sich von der erwarteten Freigabepause; lies die Konsole und kehre zu Configure zurück, um die bereitgestellten Stages wiederherzustellen, falls du sie versehentlich bearbeitet hast.

Selbstprüfung: Du hast beide tatsächlichen erfolgreichen Builds, die echte Freigabe des früheren Durchlaufs und das veraltete Besucherergebnis aufbewahrt. Die separate Seed-Swap-Mitteilung und ihr Download funktionieren weiterhin. Spätere Reparaturen werden diese Nachweise nicht löschen.

Lasse neue Durchläufe ältere wartende Durchläufe ablösen

In diesem Schritt verhinderst du, dass eine alte Freigabe die neueste Anforderung überschreibt. Beginne in Jenkins auf der Jobseite publish-walk-notice.

Ergänze die Regel für Überlappungen desselben Jobs

Der Block options einer Pipeline steuert das Durchlaufverhalten. disableConcurrentBuilds() allein lässt neue Durchläufe in einer Warteschlange warten, bis der aktuelle Durchlauf endet. Damit bliebe die ältere Freigabe maßgeblich. Die Einstellung abortPrevious: true unterbricht stattdessen einen älteren Durchlauf, wenn ein neuerer Durchlauf desselben Jobs startet. true ist ein boolescher Wert, kein Text in Anführungszeichen. Der Doppelpunkt übergibt diese benannte Option an die Einstellung.

Wähle Configure, suche Pipeline → Script und füge die folgende Zeile direkt nach agent any innerhalb des äußeren Blocks pipeline und vor parameters ein:

    options { disableConcurrentBuilds(abortPrevious: true) }

Der Anfang sollte jetzt so aussehen:

pipeline {
    agent any
    options { disableConcurrentBuilds(abortPrevious: true) }
    parameters {

Dieser kleine Ausschnitt zeigt die Platzierung; ersetze nicht das gesamte Script durch den Ausschnitt. Behalte die vorhandenen Parameter, Stages, Archivierung und Bereinigung bei. Wähle Save. Das Speichern ändert künftige Durchläufe; du musst ein neues Paar ausführen, um die Wirkung nachzuweisen.

Beobachte die automatische Ablösung

Wähle auf der Jobseite Build with Parameters, wähle later-start, aktiviere HOLD_FOR_REVIEW und wähle Build. Öffne Console Output des neuen älteren Durchlaufs und warte auf die tatsächliche Aufforderung Proceed / Abort. Bei einem unveränderten Durchgang ist dies #3. Lasse ihn warten; brich ihn nicht manuell ab und setze ihn nicht fort.

Kehre über den Brotkrumenlink zum Job zurück. Wähle Build with Parameters, wähle new-meeting-point, lasse HOLD_FOR_REVIEW deaktiviert und wähle dann Build. Öffne die Konsole dieses neueren Durchlaufs und warte auf Finished: SUCCESS. Bei einem unveränderten Durchgang ist dies #4.

Öffne die Konsole des älteren wartenden Durchlaufs und lade sie neu. Auf der vorbereiteten Jenkins-Version hat der Durchlauf den Status NOT_BUILT, mit Superseded by #... und der Nummer des neueren Durchlaufs. Die alte Stage Publish notice wurde übersprungen und die Bereinigung trotzdem ausgeführt. Ein grauer Status allein reicht nicht: Lies die Ursache der Ablösung und vergleiche die neuere Buildnummer. Die alte Eingabe wartet nicht mehr auf deine Freigabe. Die historische Konsole kann weiterhin ihren früheren Proceed/Abort-Text anzeigen; verwende diese alten Links nach der Ablösung nicht.

Lies Superseded by #... und die übersprungene Veröffentlichungsstage und vergleiche dann das endgültige Ergebnis NOT_BUILT.

NOT_BUILT bedeutet hier nicht, dass keine Arbeit stattgefunden hat. Der ältere Durchlauf hat sein Paket vor der Pause vorbereitet und archiviert. Öffne seine Build Artifacts und prüfe, ob notice-pack.zip weiterhin heruntergeladen werden kann. Die Regel hat die spätere Veröffentlichung dieses veralteten Pakets verhindert. Die Workspace-Bereinigung beider Durchläufe lässt diese archivierten Dateien unverändert erhalten.

Wechsle zu Notice Desk, lade die Seite neu und öffne die Gartenmitteilung. Sie muss 10:30 bei Glasshouse Gate zeigen. Lies Route, Hinweise und Zeitplan.

Prüfe 10:30, Glasshouse Gate und den ersten Haltepunkt der Route gemeinsam. Kehre zur Startseite zurück und prüfe, ob Seed Swap weiterhin um 11:00 bei Potting Shed beginnt.

Übe das Abbrechen einer versehentlichen Freigabepause

Wechsle zu Jenkins. Starte einen weiteren Build von later-start mit aktiviertem HOLD_FOR_REVIEW. Warte auf seine Konsoleneingabeaufforderung und wähle dann Abort. Dies ist ein absichtliches manuelles Abbrechen, das mit ABORTED endet. Es unterscheidet sich von der bereits beobachteten automatischen Ablösung und ersetzt diesen Nachweis nicht. Die veröffentlichte Mitteilung bleibt bei Glasshouse Gate, weil dieser Durchlauf nie veröffentlicht hat.

Starte einen abschließenden Build von new-meeting-point mit deaktiviertem HOLD_FOR_REVIEW und warte auf SUCCESS. Dies ist die Wiederherstellung, falls du versehentlich die falsche Anforderung anhältst oder abbrichst: Prüfe die Redakteursseite, wähle die neueste Anforderung und baue sie ohne Wartepause. Behalte die älteren Durchläufe bei; das Löschen des Verlaufs würde Nachweise über das Verhalten der Regel entfernen.

Falls das Speichern eines Scripts zu FAILURE mit einer Syntaxmeldung führt, prüfe die Klammerpaare und stelle sicher, dass die Zeile options innerhalb von pipeline steht, nicht innerhalb von stages oder den steps einer Stage. Korrigiere sie in Configure, speichere und starte das beabsichtigte Paar erneut. Setze die VM nicht zurück und ändere die bereitgestellten Werkzeuge nicht. Zusätzliche fehlgeschlagene Versuche können im Verlauf bleiben.

Bewahre das fertige Ergebnis auf und untersuche es

Wechsle zu Notice Desk. Lade die Seite neu und lade dann das notice pack des Gartenspaziergangs herunter. Speichere es in einem neuen Ordner, statt Dateien aus früheren Downloads zu mischen. Entpacke die gesamte ZIP-Datei und öffne index.html. Prüfe Glasshouse Gate, 10:30, die illustrierte Route und alle drei Haltepunkte. Öffne Read visitor notes, Schedule table, Notice details und Preparation record. CSV- und JSON-Datei müssen mit der Seite übereinstimmen; publication.txt nennt den abschließenden erfolgreichen Jenkins-Job und Build. Der vollständige Ordner funktioniert lokal ohne Jenkins oder Notice Desk. Verwende zwischen lokalen Dateiansichten die Browseraktion Back.

Öffne in Jenkins den zugehörigen erfolgreichen Build und Build Artifacts und lade dann notice-pack.zip herunter. Seine sieben entpackten Dateien müssen mit dem Download von Notice Desk übereinstimmen. Systemeigene Jenkins-Archive dokumentieren, was ein Build vorbereitet hat; Notice Desk zeigt, was tatsächlich veröffentlicht wurde.

Selbstprüfung: Die gespeicherte Regel ist aktiv, ein tatsächlicher neuerer Durchlauf hat automatisch einen älteren an der Eingabe angehaltenen Durchlauf abgelöst und Besucher erhalten die echten Dateien der neuesten Anforderung. Das Paar aus angehaltenem und neuerem Durchlauf muss dieses gespeicherte Script ausgeführt haben. Dein neuester abgeschlossener Durchlauf muss selbst eine erfolgreiche Veröffentlichung der neuesten Anforderung sein; stelle nach einer fehlerhaften oder übersprungenen Veröffentlichung das Script wieder her und führe es erneut aus. Falls du sein Verhalten erneut änderst, weise ein neues Paar aus angehaltenem und neuerem Durchlauf nach. Der gesamte Buildverlauf, frühere Archive, das Vorbereitungs-, Prüf-, Veröffentlichungs- und Bereinigungsverhalten sowie die unabhängige Veranstaltung bleiben erhalten.

Diese Einstellung betrifft Überlappungen innerhalb eines Jobs. Sie kann keine Veröffentlichung rückgängig machen, die vor der Unterbrechung stattgefunden hat, keine unterschiedlichen Jobs koordinieren und nicht jede produktive Bereitstellung sicher abbrechbar machen. Hier pausiert der ältere Durchlauf vor seinem einzigen Veröffentlichungsschritt, wodurch die Grenze klar ist.

Zusammenfassung

Du hast ein tatsächliches Ergebnis für Besucher mit dem Verhalten von Jenkins-Durchläufen verknüpft. Du hast nachgestellt, wie eine ältere Freigabe eine neuere Mitteilung überschreibt, und dann disableConcurrentBuilds(abortPrevious: true) verwendet, damit neue Durchläufe ältere wartende Durchläufe desselben Jobs unterbrechen. Du hast Vorbereitung von Veröffentlichung, systemeigene Ablösung von manuellem Abbrechen und archivierte Dateien von Workspace-Dateien unterschieden.

Dein fertiges Ergebnis ist die neueste Gartenmitteilung mit passender Offline-Route, passendem Zeitplan und passenden Hinweisen. Der erhaltene Verlauf zeigt, warum ihr erfolgreicher Build bedeutet, dass die beabsichtigte Aktualisierung die Besucher tatsächlich erreicht hat.