Introduction
Walk Weekender a confirmé une édition de son dossier visiteurs Riverwalk Saturday. Une version de travail plus récente a également été produite avec succès. Le job de livraison doit récupérer le dossier confirmé depuis son exécution Jenkins existante, sans le reconstruire ni dépendre d’un espace de travail qui a été vidé.
Ce lab suppose que vous connaissez les notions d’archivage, de nettoyage de l’espace de travail et d’empreinte enseignées dans Conserver un dossier événementiel téléchargeable, ainsi que la navigation de base dans Jenkins et l’extraction d’un ZIP. Cette unité démarre de manière indépendante : son historique source, le dossier actuellement disponible et le job de livraison sont déjà préparés. Vous n’avez besoin ni des fichiers ni d’une machine virtuelle en cours d’exécution du lab précédent.
Utilisez Pack Desk pour examiner les véritables fichiers visiteurs et Jenkins pour examiner et configurer les jobs. Il s’agit de deux services dans une même machine virtuelle préparée. Le plugin Copy Artifact est déjà disponible. Le mécanisme de publication fourni est un petit service récepteur local de formation qui vérifie cette demande ; ce n’est ni un registre d’artefacts de production ni un service d’approbation. Vous sélectionnerez une exécution déjà confirmée, sans mettre en œuvre un processus d’approbation. La durée est une estimation de l’auteur, et non une mesure réalisée auprès de débutants.
Comparer la demande au dossier copié
Dans cette étape, vous identifierez l’exécution source confirmée, puis observerez un job de livraison copier une autre édition. Commencez dans Pack Desk.
Lisez Requested edition: RW-02. L’activité est Riverwalk Saturday et le job source est create-riverwalk-pack. Choisissez Open the current pack. L’édition actuelle est RW-01, avec un rendez-vous à 10:30. Le dossier demandé doit remplacer cette édition antérieure tout en laissant disponible le dossier Parkside distinct. Utilisez l’action Back du navigateur pour revenir au bureau.
Passez à Jenkins, ouvrez create-riverwalk-pack et examinez ses builds numérotés sous Builds. Les numéros de build appartiennent à un job donné ; un numéro seul ne constitue pas une identité globale d’artefact. Ouvrez Console Output pour chaque build afin de lire l’édition visiteurs préparée et le résultat final. L’historique contient :
| Build | Édition visiteurs | Résultat | Signification pour cette demande |
|---|---|---|---|
| #1 | Parkside Paper Trail / PP-01 | SUCCESS | Une autre activité |
| #2 | Riverwalk Saturday / RW-02 | SUCCESS | Le dossier confirmé existant |
| #3 | Riverwalk Saturday / RW-03-DRAFT | SUCCESS | Une version de travail plus récente, différente de la demande |
| #4 | Riverwalk Saturday / RW-02 | FAILURE | Une exécution en échec, même si elle a conservé un ZIP |
Ouvrez le build #2 à l’aide de son lien dans le fil d’Ariane, téléchargez event-pack.zip sous Build Artifacts et extrayez l’archive complète. Sa vue d’ensemble et ses notes indiquent RW-02 et 10:00. Sa console se termine par le nettoyage de l’espace de travail. L’archive appartient au build : le job de livraison peut donc la récupérer après ce nettoyage.
Conservez cet historique source existant. Ne configurez, ne relancez, ne supprimez et ne renommez ni les jobs sources ni leurs builds. Seuls le Pipeline deliver-riverwalk-pack et ses paramètres de build entrent dans le périmètre. Conservez les fichiers, le mécanisme de publication, l’archivage et le nettoyage fournis, et laissez le dossier Parkside distinct intact.
Utilisez le lien Dashboard dans le fil d’Ariane, ouvrez deliver-riverwalk-pack, puis choisissez Configure et la section Pipeline. Lisez l’étape Copy archive sans encore la modifier :
copyArtifacts projectName: params.SOURCE_JOB,
selector: lastSuccessful(),
filter: 'event-pack.zip',
fingerprintArtifacts: true
copyArtifacts récupère les artefacts conservés d’un autre job Jenkins. projectName sélectionne ce job ; params.SOURCE_JOB lit la valeur saisie pour cette exécution de livraison. filter choisit les fichiers dans son archive. Le sélecteur détermine l’exécution source numérotée à utiliser. lastSuccessful() est une sélection variable : elle désigne la dernière exécution réussie au moment de cette copie, et non l’édition de votre demande. fingerprintArtifacts: true enregistre l’utilisation du fichier pour le suivre entre les jobs.
L’étape Archive delivery fournie conserve le ZIP copié dans le build de livraison. Deliver pack envoie ces mêmes octets copiés au bureau local. Le nettoyage final post vide l’espace de travail de livraison. Conservez ces parties sans modification. Choisissez Save sans modifier le script.
Choisissez Build with Parameters. Attendez la fin du chargement du formulaire. Réglez SOURCE_JOB sur create-riverwalk-pack et SOURCE_BUILD sur 2, puis choisissez Build. Ces valeurs décrivent la source souhaitée ; le sélecteur actuel ignore toujours SOURCE_BUILD.
Attendez que ce build de livraison se termine avec FAILURE, puis ouvrez Console Output. Vous devez voir Copied 1 artifact depuis le build source 3, suivi de The package bytes differ from the selected source archive. Le mécanisme de publication renvoie le code HTTP 422 : le service a été atteint, mais il a rejeté le paquet sélectionné. Cela diffère d’un échec de connexion. L’étape shell renvoie un résultat non nul, ce qui fait échouer le build.
Ouvrez event-pack.zip pour ce build de livraison sous Build Artifacts, extrayez-le dans un dossier distinct et lisez sa vue d’ensemble. Il contient RW-03-DRAFT, car le build #3 est la dernière exécution source réussie. Un ZIP conservé et une exécution source verte ne suffisent pas à identifier l’édition demandée.
Passez à Pack Desk, actualisez la page et ouvrez de nouveau le dossier actuel. Il doit toujours indiquer RW-01 et 10:30. La tentative rejetée ne doit pas remplacer des documents visiteurs valides. Revenez au bureau avec l’action Back du navigateur.
Livrer et suivre l’exécution confirmée
Dans cette étape, vous copierez l’exécution confirmée explicitement désignée et vérifierez les fichiers visiteurs livrés ainsi que leur suivi dans Jenkins. Commencez sur la page du job deliver-riverwalk-pack dans Jenkins.
Choisissez Configure, puis Pipeline. Dans Script, remplacez uniquement :
selector: lastSuccessful(),
par :
selector: specific(params.SOURCE_BUILD),
specific(...) sélectionne explicitement un numéro de build source. params.SOURCE_BUILD lit la chaîne saisie dans le formulaire de build ; avec SOURCE_JOB, elle identifie une exécution existante. Conservez la virgule : le paramètre filter suivant appartient à la même opération copyArtifacts. Conservez la valeur RECEIVER_URL fournie, toutes les autres étapes et le nettoyage final.
Dans Script, repérez la ligne du sélecteur sous Copy archive. Attendez la fin du chargement du code et faites défiler le contenu de l’éditeur si nécessaire. Double-cliquez sur lastSuccessful pour sélectionner uniquement ce nom de fonction, puis saisissez specific. Les parenthèses vides restent en place. Avec le curseur immédiatement après specific, appuyez une fois sur la touche Right Arrow pour entrer dans (), puis saisissez params.SOURCE_BUILD. Vérifiez la ligne complète du sélecteur ci-dessus avant d’enregistrer. Si vous remplacez accidentellement davantage de texte, utilisez Ctrl+Z sous Windows/Linux ou Command+Z sous macOS avant d’enregistrer, puis réessayez. Choisissez Save.
Lancez de nouveau Build with Parameters. Attendez la fin du chargement du formulaire, saisissez create-riverwalk-pack pour SOURCE_JOB et 2 pour SOURCE_BUILD, puis choisissez Build. Attendez SUCCESS. Sa console doit montrer la copie de l’artefact, les actions d’archivage et d’enregistrement de l’empreinte, une réponse contenant delivered et le nettoyage final de l’espace de travail.
Si Jenkins signale une erreur de syntaxe Groovy, revenez à Configure et vérifiez la ligne du sélecteur, les parenthèses et la virgule par rapport au remplacement exact ci-dessus. Enregistrez et relancez avec les mêmes valeurs. Si la console signale un projet, un build ou un artefact manquant, vérifiez les deux valeurs du formulaire et le build source #2. Ne relancez pas le job source pour fabriquer une nouvelle exécution. Une réponse The selected source run does not satisfy this delivery request. signifie que le job ou le numéro de build est incorrect. The package bytes differ from the selected source archive. signifie que le ZIP copié ne correspond pas à l’exécution source désignée par ces paramètres. Dans les deux cas, il s’agit d’un refus métier après avoir atteint le bureau.
Ouvrez la page d’état du build de livraison réussi et choisissez See Fingerprints. Dans Recorded Fingerprints, le lien Original owner de la ligne event-pack.zip doit mener au build #2 de create-riverwalk-pack. Choisissez le lien event-pack.zip pour ouvrir ses détails. Le lien du build ayant introduit le fichier doit identifier cette exécution source, et Usage doit inclure votre exécution réussie de deliver-riverwalk-pack. Ce sont les enregistrements Jenkins de l’origine et de l’utilisation du même fichier. Ils ne certifient pas qui a approuvé une édition et ne fournissent pas de signature cryptographique d’un éditeur.
Lisez le lien du build ayant introduit le fichier près du haut de la page et les deux jobs sous Usage. Le numéro de votre build de livraison peut différer de cet exemple.
Téléchargez event-pack.zip depuis ce build de livraison réussi. Extrayez-le dans un nouveau dossier, ouvrez index.html et confirmez Riverwalk Saturday, RW-02 et 10:00. Ouvrez Explore the route et vérifiez les trois étapes ainsi que l’affichage de l’image du parcours. Choisissez Download all route stops pour le CSV et Read the visitor notes pour le texte local. Les notes peuvent s’ouvrir directement dans le navigateur au lieu de déclencher un autre téléchargement ; le fichier texte d’origine se trouve déjà dans le dossier extrait. Conservez les huit fichiers ensemble, y compris build.json, dont job et number identifient create-riverwalk-pack et 2.
Passez à Pack Desk et actualisez la page. Le dossier actuel doit maintenant indiquer RW-02. Ouvrez-le et répétez les vérifications du parcours, du CSV et des notes. Revenez avec l’action Back du navigateur, puis choisissez Download the current ZIP. Ce téléchargement doit être l’archive source d’origine complète, et non une version reconstruite pour la remplacer. Le récepteur compare les octets réels avant de changer le dossier actuel.
Enfin, choisissez Parkside pack dans la navigation du bureau et confirmez que Parkside Paper Trail s’ouvre toujours avec son parcours et ses notes. L’historique des builds sources et tous les fichiers fournis doivent rester intacts. Après toute modification supplémentaire du Pipeline, exécutez de nouveau le Pipeline enregistré avant de vérifier que le travail est terminé.
Résumé
Vous avez récupéré un dossier visiteurs confirmé depuis un build Jenkins existant après le nettoyage de son espace de travail. Vous avez vu pourquoi un sélecteur variable pouvait choisir une version de travail produite avec succès, utilisé un job et un numéro de build explicites, puis suivi l’archive d’origine grâce aux empreintes Jenkins jusqu’à un job de livraison distinct. Le bureau sert désormais les fichiers visiteurs d’origine complets, tandis que l’autre activité reste disponible.
