Einführung
Walk Weekender hat eine Ausgabe seines Besucherpakets für Riverwalk Saturday bestätigt. Auch ein späterer Entwurf wurde erfolgreich erstellt. Der Auslieferungsjob muss das bestätigte Paket aus seinem vorhandenen Jenkins-Durchlauf abrufen, ohne es neu zu erstellen oder von einem geleerten Arbeitsverzeichnis abhängig zu sein.
Dieses Lab setzt die Konzepte zu Archivierung, Workspace-Bereinigung und Fingerprints aus Bewahre ein herunterladbares Veranstaltungspaket auf sowie grundlegende Kenntnisse der Navigation in Jenkins und des Entpackens von ZIP-Dateien voraus. Diese Einheit beginnt unabhängig: Ihr Quellverlauf, das bisherige aktuelle Paket und der Auslieferungsjob sind bereits vorbereitet. Du benötigst weder Dateien noch eine laufende VM aus dem vorherigen Lab.
Verwende Pack Desk, um die tatsächlichen Besucherdateien zu untersuchen, und Jenkins, um Jobs zu prüfen und zu konfigurieren. Dies sind zwei Dienste in einer vorbereiteten VM. Das Plugin Copy Artifact ist bereits verfügbar. Der bereitgestellte Veröffentlichungsschritt verwendet einen kleinen lokalen Übungsempfänger, der diese Anforderung prüft; er ist weder eine produktive Artefaktregistrierung noch ein Freigabedienst. Du wählst einen bereits bestätigten Durchlauf aus und implementierst keinen Freigabeprozess. Die Dauer ist eine Schätzung des Autors, keine mit Anfängern gemessene Zeit.
Vergleiche die Anforderung mit dem kopierten Paket
In diesem Schritt ermittelst du den bestätigten Quelldurchlauf und beobachtest anschließend, wie ein Auslieferungsjob eine andere Ausgabe kopiert. Beginne in Pack Desk.
Lies Requested edition: RW-02. Die Aktivität heißt Riverwalk Saturday, und der Quelljob ist create-riverwalk-pack. Wähle Open the current pack. Die aktuelle Ausgabe ist RW-01 mit der Treffzeit 10:30. Das angeforderte Paket soll diese frühere Ausgabe ersetzen, während das separate Parkside-Paket verfügbar bleibt. Kehre mit der Browseraktion Back zum Desk zurück.
Wechsle zu Jenkins, öffne create-riverwalk-pack und untersuche seine nummerierten Builds unter Builds. Buildnummern gehören zu einem einzelnen Job; eine Nummer allein ist keine globale Artefaktidentität. Öffne Console Output jedes Builds, um die vorbereitete Besucherausgabe und das endgültige Ergebnis zu lesen. Der Verlauf enthält:
| Build | Besucherausgabe | Ergebnis | Bedeutung für diese Anforderung |
|---|---|---|---|
| #1 | Parkside Paper Trail / PP-01 | SUCCESS | Eine andere Aktivität |
| #2 | Riverwalk Saturday / RW-02 | SUCCESS | Das vorhandene bestätigte Paket |
| #3 | Riverwalk Saturday / RW-03-DRAFT | SUCCESS | Ein neuerer Entwurf, nicht die Anforderung |
| #4 | Riverwalk Saturday / RW-02 | FAILURE | Ein erfolgloser Durchlauf, obwohl er eine ZIP-Datei aufbewahrt hat |
Öffne Build #2 über seinen Link in der Brotkrumennavigation, lade event-pack.zip unter Build Artifacts herunter und entpacke das vollständige Archiv. Seine Übersicht und Hinweise zeigen RW-02 und 10:00. Seine Konsole endet mit der Bereinigung des Arbeitsverzeichnisses. Das Archiv gehört zum Build, daher kann der Auslieferungsjob es nach dieser Bereinigung abrufen.
Behalte diesen vorhandenen Quellverlauf bei. Konfiguriere keine Quelljobs oder deren Builds, führe sie nicht erneut aus und lösche oder benenne sie nicht um. Nur die Pipeline von deliver-riverwalk-pack und ihre Buildparameter gehören zum erlaubten Umfang. Behalte die bereitgestellten Dateien, den Veröffentlichungsschritt, die Archivierung und die Bereinigung bei und lasse das separate Parkside-Paket unverändert.
Verwende den Brotkrumenlink Dashboard, öffne deliver-riverwalk-pack und wähle dann Configure und den Abschnitt Pipeline. Lies die Stage Copy archive, ohne sie bereits zu ändern:
copyArtifacts projectName: params.SOURCE_JOB,
selector: lastSuccessful(),
filter: 'event-pack.zip',
fingerprintArtifacts: true
copyArtifacts ruft aufbewahrte Artefakte aus einem anderen Jenkins-Job ab. projectName wählt diesen Job aus; params.SOURCE_JOB liest den für diesen Auslieferungsdurchlauf eingegebenen Wert. filter wählt Dateien innerhalb seines Archivs aus. Der Selektor bestimmt, welcher nummerierte Quelldurchlauf verwendet wird. lastSuccessful() ist eine veränderliche Auswahl: Sie bezeichnet den neuesten erfolgreichen Durchlauf zum Zeitpunkt des Kopierens, nicht die Ausgabe in deiner Anforderung. fingerprintArtifacts: true erfasst die Dateiverwendung zur Nachverfolgung zwischen Jobs.
Die bereitgestellte Stage Archive delivery bewahrt die kopierte ZIP-Datei beim Auslieferungsbuild auf. Deliver pack sendet exakt diese kopierten Bytes an den lokalen Desk. Die abschließende Bereinigung unter post leert das Arbeitsverzeichnis der Auslieferung. Behalte diese Teile unverändert bei. Wähle Save, ohne etwas zu bearbeiten.
Wähle Build with Parameters. Warte, bis das Formular vollständig geladen ist. Setze SOURCE_JOB auf create-riverwalk-pack und SOURCE_BUILD auf 2 und wähle dann Build. Diese Werte beschreiben die beabsichtigte Quelle; der aktuelle Selektor ignoriert SOURCE_BUILD weiterhin.
Warte, bis dieser Auslieferungsbuild mit FAILURE endet, und öffne dann Console Output. Erwarte Copied 1 artifact aus Quellbuild 3, gefolgt von The package bytes differ from the selected source archive. Der Veröffentlichungsempfänger gibt HTTP 422 zurück: Der Dienst wurde erreicht, hat das ausgewählte Paket aber abgelehnt. Das unterscheidet sich von einem Verbindungsfehler. Der Shellschritt meldet ein Ergebnis ungleich null, sodass der Build fehlschlägt.
Öffne event-pack.zip dieses Auslieferungsbuilds unter Build Artifacts, entpacke es in einen separaten Ordner und lies seine Übersicht. Es enthält RW-03-DRAFT, weil Build #3 der letzte erfolgreiche Quelldurchlauf ist. Eine aufbewahrte ZIP-Datei und ein grüner Quelldurchlauf reichen nicht aus, um die angeforderte Ausgabe zu bestimmen.
Wechsle zu Pack Desk, lade die Seite neu und öffne das aktuelle Paket erneut. Es muss weiterhin RW-01 und 10:30 zeigen. Der abgelehnte Versuch darf gültige Besuchermaterialien nicht ersetzen. Kehre mit der Browseraktion Back zum Desk zurück.
Liefere den bestätigten Durchlauf aus und verfolge ihn nach
In diesem Schritt kopierst du den ausdrücklich gewählten bestätigten Durchlauf und prüfst die ausgelieferten Besucherdateien sowie ihre Nachverfolgung in Jenkins. Beginne auf der Jobseite von deliver-riverwalk-pack in Jenkins.
Wähle Configure und dann Pipeline. Ändere in Script ausschließlich:
selector: lastSuccessful(),
in:
selector: specific(params.SOURCE_BUILD),
specific(...) wählt eine ausdrückliche Quellbuildnummer aus. params.SOURCE_BUILD liest die im Buildformular eingegebene Zeichenkette; zusammen mit SOURCE_JOB bezeichnet sie einen vorhandenen Durchlauf. Behalte das Komma bei: Die folgende Einstellung filter gehört zur selben Operation copyArtifacts. Behalte den bereitgestellten Wert für RECEIVER_URL, alle anderen Stages und die abschließende Bereinigung bei.
Suche in Script die Selektorzeile unter Copy archive. Warte, bis der Code vollständig geladen ist, und scrolle bei Bedarf innerhalb des Editors. Doppelklicke auf lastSuccessful, um nur diesen Funktionsnamen auszuwählen, und tippe dann specific. Die leeren runden Klammern bleiben erhalten. Drücke mit dem Cursor unmittelbar nach specific einmal die Taste Right Arrow, um in () zu wechseln, und tippe dann params.SOURCE_BUILD. Prüfe vor dem Speichern die vollständige oben gezeigte Selektorzeile. Falls du versehentlich mehr Text ersetzt, verwende vor dem Speichern Ctrl+Z unter Windows/Linux oder Command+Z unter macOS und versuche es erneut. Wähle Save.
Führe erneut Build with Parameters aus. Warte, bis das Formular vollständig geladen ist, gib create-riverwalk-pack für SOURCE_JOB und 2 für SOURCE_BUILD ein und wähle dann Build. Warte auf SUCCESS. Seine Konsole sollte das kopierte Artefakt, die Archivierungs- und Fingerprint-Aktionen, eine Antwort mit delivered und die abschließende Bereinigung des Arbeitsverzeichnisses zeigen.
Falls Jenkins einen Groovy-Syntaxfehler meldet, kehre zu Configure zurück und vergleiche die Selektorzeile, die runden Klammern und das Komma mit der exakten Ersetzung oben. Speichere und führe den Job mit denselben Werten erneut aus. Falls die Konsole ein fehlendes Projekt, einen fehlenden Build oder ein fehlendes Artefakt meldet, prüfe die beiden Formularwerte und Quellbuild #2. Führe den Quelljob nicht erneut aus, um einen neuen Durchlauf herzustellen. Eine Antwort mit The selected source run does not satisfy this delivery request. bedeutet, dass der Job oder die Buildnummer falsch ist. The package bytes differ from the selected source archive. bedeutet, dass die kopierte ZIP-Datei nicht zu dem durch diese Parameter bezeichneten Quelldurchlauf passt. Beides sind fachliche Ablehnungen, nachdem der Desk erreicht wurde.
Öffne die Statusseite des erfolgreichen Auslieferungsbuilds und wähle See Fingerprints. Unter Recorded Fingerprints muss Original owner in der Zeile event-pack.zip zu create-riverwalk-pack, Build #2, führen. Wähle den Link event-pack.zip, um die Details zu öffnen. Der Link zum Build, der die Datei eingeführt hat, sollte diesen Quelldurchlauf bezeichnen, und Usage muss deinen erfolgreichen Durchlauf von deliver-riverwalk-pack enthalten. Das sind Jenkins-Aufzeichnungen über den Ursprung und die Verwendung derselben Datei. Sie bestätigen nicht, wer eine Ausgabe freigegeben hat, und stellen keine kryptografische Signatur eines Herausgebers bereit.
Lies den Link zum einführenden Build nahe dem Seitenanfang und die beiden Jobs unter Usage. Deine Auslieferungsbuildnummer kann von diesem Beispiel abweichen.
Lade event-pack.zip von diesem erfolgreichen Auslieferungsbuild herunter. Entpacke es in einen neuen Ordner, öffne index.html und prüfe Riverwalk Saturday, RW-02 und 10:00. Öffne Explore the route und prüfe alle drei Haltepunkte sowie das dargestellte Routenbild. Wähle Download all route stops für die CSV-Datei und Read the visitor notes für den lokalen Text. Die Hinweise öffnen sich möglicherweise direkt im Browser, anstatt einen weiteren Download zu starten; die ursprüngliche Textdatei befindet sich bereits im entpackten Ordner. Behalte alle acht Dateien zusammen, einschließlich build.json, dessen job und number die Werte create-riverwalk-pack und 2 angeben.
Wechsle zu Pack Desk und lade die Seite neu. Das aktuelle Paket muss jetzt RW-02 zeigen. Öffne es und wiederhole die Prüfungen von Route, CSV-Datei und Hinweisen. Kehre mit der Browseraktion Back zurück und wähle dann Download the current ZIP. Dieser Download muss das vollständige ursprüngliche Quellarchiv sein, kein neu erstellter Ersatz. Der Empfänger vergleicht die tatsächlichen Bytes, bevor er das aktuelle Paket ändert.
Wähle abschließend Parkside pack in der Desk-Navigation und prüfe, ob Parkside Paper Trail weiterhin mit seiner Route und seinen Hinweisen geöffnet wird. Der Quellbuildverlauf und alle bereitgestellten Dateien müssen unverändert erhalten bleiben. Führe nach jeder weiteren Pipeline-Bearbeitung die gespeicherte Pipeline erneut aus, bevor du den Abschluss prüfst.
Zusammenfassung
Du hast ein bestätigtes Besucherpaket aus einem vorhandenen Jenkins-Build abgerufen, nachdem sein Arbeitsverzeichnis geleert worden war. Du hast gesehen, warum eine veränderliche Auswahl einen erfolgreichen Entwurf auswählen konnte, einen ausdrücklichen Job und eine Buildnummer verwendet und das ursprüngliche Archiv über Jenkins-Fingerprints bis zu einem separaten Auslieferungsjob verfolgt. Der Desk stellt jetzt die vollständigen ursprünglichen Besucherdateien bereit, während die separate Aktivität verfügbar bleibt.
