Garder la dernière annonce en ligne

Introduction

Pine & Path prépare une promenade dans un jardin. Un premier rédacteur demande un départ plus tardif ; un autre change ensuite le lieu de rendez-vous. Jenkins peut préparer et publier chacune des annonces, mais une ancienne exécution en attente d’approbation pourrait écraser l’annonce plus récente après sa mise à disposition des visiteurs.

Vous observerez cet écrasement, puis modifierez le Pipeline pour qu’une nouvelle exécution remplace automatiquement une ancienne exécution en attente. Votre résultat sera une véritable annonce pour les visiteurs et un dossier téléchargeable de sept fichiers, dont le parcours, les horaires et les notes correspondent tous à la dernière demande.

Les prérequis sont la navigation de base dans les pages Jenkins et la reconnaissance d’un court Pipeline déclaratif. Les paramètres, les pauses d’approbation et le réglage de concurrence sont expliqués ici. Jenkins, deux exécuteurs du contrôleur, les outils d’annonce et le service local Notice Desk sont préparés. Vous n’installez pas de logiciels et n’écrivez pas le site web. Les deux interfaces fonctionnent sur une même machine virtuelle de formation ; il s’agit d’un service de publication local contrôlé, et non d’une plateforme de déploiement de production. La durée est une estimation de l’auteur, et non une mesure réalisée auprès de débutants.

Observer une approbation tardive écraser une annonce

Dans cette étape, vous publierez la dernière annonce, puis observerez une ancienne exécution en attente l’écraser. Commencez dans Notice Desk. Gardez cette interface ouverte ; changer d’interface ne redémarre pas un build et ne réinitialise pas l’annonce.

Examiner le parcours normal des visiteurs

Le premier événement est la promenade dans le jardin. Choisissez son lien View notice. L’annonce fournie indique un départ à 10:00 à Community Gate. Ouvrez Open the route et examinez les trois étapes. Utilisez l’action Back du navigateur pour revenir à l’annonce. Ouvrez Read visitor notes, lisez les instructions de rendez-vous, puis utilisez de nouveau Back. Schedule table est un fichier CSV : un tableau simple dont les champs sont séparés par des virgules. Notice details est du JSON : des valeurs nommées décrivant le même événement. Preparation record identifie la préparation de ce dossier. À ce stade, il indique honnêtement PROVIDED BASELINE ; la préparation de l’environnement n’a pas exécuté le job Jenkins à votre place.

Utilisez l’action Back du navigateur pour revenir à l’accueil de Notice Desk. Choisissez Download notice pack pour la promenade et enregistrez l’archive ZIP. Un ZIP garde plusieurs fichiers ensemble. Extrayez l’archive entière dans un nouveau dossier avec l’outil de gestion des archives de votre ordinateur, puis ouvrez son index.html. Gardez les sept fichiers voisins ensemble. Le parcours, la feuille de style, les horaires, les notes, le JSON et la fiche de préparation sont de véritables fichiers locaux ; déplacer seulement index.html cassera ses liens vers les fichiers voisins. Votre navigateur peut ouvrir un fichier CSV/texte ou le télécharger ; les deux comportements conviennent pour lire les octets enregistrés.

Revenez à l’accueil de Notice Desk. Examinez l’annonce distincte Seed Swap et son téléchargement. Elle commence à 11:00 à Potting Shed et doit rester inchangée. Les prochaines demandes des rédacteurs concernent uniquement la promenade dans le jardin.

Choisissez Read the editor requests. La première demande utilise la valeur UPDATE later-start : 10:30, toujours à Community Gate. La dernière demande est new-meeting-point : conserver 10:30, mais se retrouver à Glasshouse Gate. Ici, « dernière » désigne la demande la plus récente des rédacteurs, et non le build qui termine en dernier.

Lire le Pipeline préparé

Passez à Jenkins. Ouvrez publish-walk-notice, puis Configure. Repérez la section Pipeline et son éditeur Script. Il s’agit d’un Pipeline déclaratif : le bloc extérieur pipeline { ... } décrit le travail, et les accolades correspondantes regroupent ses paramètres et ses étapes.

Le job utilise agent any, qui alloue un exécuteur et un espace de travail sur un nœud préparé disponible. Un exécuteur est un emplacement Jenkins pour exécuter du travail ; un espace de travail est le répertoire de travail d’une exécution. Ce contrôleur de formation possède deux exécuteurs : deux exécutions de ce job peuvent donc se chevaucher. Elles ont des répertoires de travail distincts, mais publient vers la même annonce de promenade.

Le bloc parameters définit les valeurs choisies pour chaque build. choice propose les deux demandes des rédacteurs sous UPDATE. booleanParam fait de HOLD_FOR_REVIEW une case à cocher : cochée signifie true, décochée signifie false. params.HOLD_FOR_REVIEW lit la valeur choisie pour cette exécution. Une condition when exécute son étape uniquement lorsque l’expression est vraie.

Les trois étapes ont des rôles distincts :

• Prepare notice vide l’espace de travail de l’exécution avec deleteDir(), appelle le programme de préparation fourni avec sh et archive notice-pack.zip. archiveArtifacts conserve ce fichier exact avec le build natif. fingerprint: true enregistre son identité de contenu et le build associé. Préparer et archiver ne modifient pas l’annonce destinée aux visiteurs.
• Review notice utilise input pour mettre en pause une exécution dont la case est cochée avant la publication. Son lien Proceed autorise l’étape suivante ; Abort annule cette exécution. Il s’agit d’une pause volontaire, et non d’un échec de connexion.
• Publish notice envoie le dossier préparé au service local Notice Desk. Le bloc post { always { ... } } vide l’espace de travail à la fin de l’exécution, y compris en cas d’interruption. Les fichiers archivés natifs restent disponibles après le nettoyage de l’espace de travail.

Les programmes de préparation et de publication fournis lisent les paramètres et l’archive du véritable build. Conservez ces programmes, toutes les étapes, la condition de revue, l’enregistrement d’empreinte et les deux opérations de nettoyage. Vous changerez uniquement la gestion du chevauchement des exécutions à l’étape suivante. Pour l’instant, laissez Script inchangé. Choisissez Save pour revenir au job.

Démarrer une ancienne exécution et la laisser attendre

Sur la page du job publish-walk-notice, choisissez Build with Parameters. Sélectionnez later-start pour UPDATE et cochez HOLD_FOR_REVIEW en cliquant sur son libellé ou sa case. Choisissez une fois Build.

Ouvrez l’exécution nouvellement démarrée dans Build History ; sur un job intact, il s’agit de #1. Ouvrez Console Output. Attendez Release this selected notice? avec les liens Proceed et Abort. Laissez-la en attente. La console a déjà indiqué la préparation et l’archivage. L’annonce partagée du job pour les visiteurs reste celle de référence, car Publish notice n’a pas été exécuté.

Utilisez le lien publish-walk-notice du fil d’Ariane en haut pour revenir à la page du job. Cette navigation reste dans Jenkins ; elle diffère du passage à l’interface Notice Desk. Notez le numéro de l’ancienne exécution pour pouvoir revenir à sa console en attente.

Choisissez de nouveau Build with Parameters. Cette fois, sélectionnez new-meeting-point et laissez HOLD_FOR_REVIEW décochée. Choisissez une fois Build. Ouvrez Console Output pour cette nouvelle exécution et attendez Finished: SUCCESS. Sur un job intact, il s’agit de #2.

Passez à Notice Desk et rechargez son accueil. Ouvrez l’annonce du jardin : 10:30 et Glasshouse Gate doivent maintenant apparaître. Ouvrez son parcours et ses notes pour les visiteurs et confirmez le même lieu de rendez-vous. La dernière demande des rédacteurs est réellement publiée.

Poursuivre l’ancienne exécution

Revenez à Jenkins. Revenez au job, ouvrez l’ancienne exécution dont vous avez noté le numéro et Console Output, puis choisissez son lien Proceed. Attendez Finished: SUCCESS. Si une ancienne console est restée ouverte, rechargez la console de cette exécution avant de choisir le lien ; ne démarrez pas un autre build simplement pour actualiser une page.

Passez à Notice Desk, rechargez la page et examinez de nouveau l’annonce du jardin. Elle indique maintenant 10:30 à Community Gate. C’est l’échec attendu : l’ancienne exécution a terminé plus tard et écrasé la demande plus récente. Les deux exécutions Jenkins ont réussi, mais le résultat métier est devenu obsolète.

Téléchargez ce dossier actuel dans un dossier différent. Son fichier publication.txt nomme l’ancienne exécution Jenkins ; son parcours, ses horaires et ses notes correspondent à cette ancienne demande. Revenez à Jenkins et ouvrez le lien Build Artifacts de cet ancien build pour télécharger son notice-pack.zip natif. Notice Desk a livré cette véritable archive préparée, au lieu de générer silencieusement une autre annonce.

Si une exécution attend de manière inattendue, examinez les Parameters choisis et sa console. Vous pouvez choisir Abort dans son invite de saisie pour annuler une exécution accidentellement en attente, puis redémarrer avec les paramètres voulus. Conservez tout l’historique des builds. Un message d’échec avant l’invite diffère de la pause d’approbation attendue ; lisez sa console et revenez à Configure pour rétablir les étapes fournies si vous les avez modifiées accidentellement.

Auto-vérification : vous avez conservé les deux véritables builds réussis, l’approbation réelle de l’ancienne exécution et le résultat obsolète destiné aux visiteurs. L’annonce distincte Seed Swap et son téléchargement fonctionnent toujours. Les corrections ultérieures n’effaceront pas ces preuves.

Laisser les nouvelles exécutions remplacer les anciennes en attente

Dans cette étape, vous empêcherez une ancienne approbation d’écraser la dernière demande. Commencez dans Jenkins sur la page du job publish-walk-notice.

Ajouter la politique de chevauchement pour un même job

Le bloc options d’un Pipeline contrôle le comportement des exécutions. disableConcurrentBuilds() seul fait attendre les nouvelles exécutions dans une file jusqu’à la fin de l’exécution actuelle. Cela laisserait l’ancienne approbation aux commandes. Le paramètre abortPrevious: true interrompt au contraire une ancienne exécution lorsqu’une nouvelle exécution de ce même job démarre. true est une valeur booléenne, et non du texte entre guillemets. Les deux-points transmettent cette option nommée au réglage.

Choisissez Configure, repérez Pipeline → Script et insérez la ligne suivante directement après agent any, dans le bloc extérieur pipeline et avant parameters :

    options { disableConcurrentBuilds(abortPrevious: true) }

Le début doit maintenant être :

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

Ce court extrait montre l’emplacement ; ne remplacez pas Script entier par cet extrait. Conservez les paramètres, étapes, archivage et nettoyage existants. Choisissez Save. L’enregistrement modifie les futures exécutions ; vous devez exécuter une nouvelle paire pour démontrer son effet.

Observer le remplacement automatique

Sur la page du job, choisissez Build with Parameters, sélectionnez later-start, cochez HOLD_FOR_REVIEW et choisissez Build. Ouvrez Console Output pour cette nouvelle exécution qui sera la plus ancienne de la paire et attendez la véritable invite Proceed / Abort. Dans un déroulement sans tentative supplémentaire, il s’agit de #3. Laissez-la en attente ; ne l’annulez pas manuellement et ne la poursuivez pas.

Revenez au job avec son fil d’Ariane. Choisissez Build with Parameters, sélectionnez new-meeting-point, laissez HOLD_FOR_REVIEW décochée, puis choisissez Build. Ouvrez la console de cette exécution plus récente et attendez Finished: SUCCESS. Dans un déroulement sans tentative supplémentaire, il s’agit de #4.

Ouvrez la console de l’ancienne exécution en attente et rechargez-la. Dans la version de Jenkins préparée, l’exécution est NOT_BUILT, avec Superseded by #... qui nomme l’exécution plus récente. L’ancienne étape Publish notice a été ignorée et le nettoyage a tout de même eu lieu. Un état gris ne suffit pas : lisez la cause du remplacement et comparez le numéro du nouveau build. L’ancienne saisie n’attend plus votre approbation. La console historique peut encore afficher son ancien texte Proceed/Abort ; n’utilisez pas ces anciens liens après le remplacement.

Lisez Superseded by #... et l’étape de publication ignorée, puis comparez le résultat final NOT_BUILT.

NOT_BUILT ne signifie pas ici qu’aucun travail n’a eu lieu. L’ancienne exécution a préparé et archivé son dossier avant la pause. Ouvrez ses Build Artifacts et confirmez que notice-pack.zip reste téléchargeable. Ce que la politique a empêché, c’est la publication ultérieure de ce dossier obsolète. Le nettoyage des espaces de travail des deux exécutions laisse ces fichiers archivés intacts.

Passez à Notice Desk, rechargez la page et ouvrez l’annonce du jardin. Elle doit indiquer 10:30 à Glasshouse Gate. Lisez le parcours, les notes et les horaires.

Vérifiez ensemble 10:30, Glasshouse Gate et la première étape du parcours. Revenez à l’accueil et vérifiez que Seed Swap commence toujours à 11:00 à Potting Shed.

S’entraîner à annuler une pause d’approbation accidentelle

Passez à Jenkins. Démarrez un autre build later-start avec HOLD_FOR_REVIEW cochée. Attendez l’invite de saisie dans sa console, puis choisissez Abort. Il s’agit d’une annulation manuelle volontaire, qui se termine par ABORTED. Elle diffère du remplacement automatique déjà observé et ne remplace pas cette preuve. L’annonce en ligne reste à Glasshouse Gate, car cette exécution n’a jamais publié.

Démarrez un dernier build new-meeting-point avec HOLD_FOR_REVIEW décochée et attendez SUCCESS. C’est l’action de récupération si vous mettez accidentellement en pause ou annulez la mauvaise demande : examinez la page des rédacteurs, sélectionnez la dernière demande et construisez-la sans pause. Conservez les anciennes exécutions ; supprimer l’historique retirerait les preuves du comportement de la politique.

Si l’enregistrement d’un Script produit FAILURE avec un message de syntaxe, vérifiez les paires d’accolades et assurez-vous que la ligne options est dans pipeline, et non dans stages ou dans les steps d’une étape. Corrigez-la dans Configure, enregistrez et redémarrez la paire prévue. Ne réinitialisez pas la machine virtuelle et ne modifiez pas les outils fournis. Les tentatives supplémentaires en échec peuvent rester dans l’historique.

Conserver et examiner le livrable final

Passez à Notice Desk. Rechargez la page, puis téléchargez le notice pack du jardin. Enregistrez-le dans un nouveau dossier au lieu de mélanger les fichiers de téléchargements précédents. Extrayez le ZIP entier et ouvrez index.html. Confirmez Glasshouse Gate, 10:30, le parcours illustré et les trois étapes. Ouvrez Read visitor notes, Schedule table, Notice details et Preparation record. Le CSV et le JSON doivent correspondre à la page ; publication.txt nomme le job et le build Jenkins réussis finaux. Le dossier complet fonctionne localement sans Jenkins ni Notice Desk. Utilisez l’action Back du navigateur entre les consultations de fichiers locaux.

Dans Jenkins, ouvrez le build réussi correspondant et Build Artifacts, puis téléchargez notice-pack.zip. Ses sept fichiers extraits doivent correspondre au téléchargement de Notice Desk. Les archives natives Jenkins documentent ce qu’un build a préparé ; Notice Desk montre ce qui a réellement été publié.

Auto-vérification : la politique enregistrée est active, une véritable nouvelle exécution a automatiquement remplacé une ancienne exécution en pause à la saisie, et les visiteurs reçoivent les véritables fichiers de la dernière demande. La paire en pause/plus récente doit avoir exécuté ce Script enregistré. Votre dernière exécution terminée doit elle-même être une publication réussie de la dernière demande ; après une publication erronée ou ignorée, rétablissez Script et relancez. Si vous changez encore son comportement, démontrez une nouvelle paire en pause/plus récente. Tout l’historique des builds, les archives précédentes, les comportements de préparation, revue, publication et nettoyage ainsi que l’événement sans rapport restent intacts.

Ce réglage agit sur le chevauchement dans un seul job. Il ne peut ni annuler une publication ayant eu lieu avant l’interruption, ni coordonner différents jobs, ni rendre tout déploiement de production sûr à interrompre. Ici, l’ancienne exécution s’arrête avant son unique étape de publication, ce qui rend la limite claire.

Résumé

Vous avez relié un véritable résultat pour les visiteurs au comportement des exécutions Jenkins. Vous avez reproduit l’écrasement d’une nouvelle annonce par une ancienne approbation, puis utilisé disableConcurrentBuilds(abortPrevious: true) pour que les nouvelles exécutions interrompent les anciennes exécutions en attente du même job. Vous avez distingué préparation et publication, remplacement natif et annulation manuelle, ainsi que fichiers archivés et fichiers d’espace de travail.

Votre produit final est la dernière annonce du jardin avec un parcours, des horaires et des notes hors ligne concordants. L’historique préservé montre pourquoi son build réussi signifie que la mise à jour voulue a réellement atteint les visiteurs.