Introduction
Cedar & Common prépare une journée de quartier. Son programme officiel est déjà disponible, et deux propositions de programme ont besoin d’aperçus distincts. Jenkins peut construire les deux branches, mais leurs Pipelines actuels publient au même endroit. Un build réussi ne suffit pas à garder les deux idées disponibles.
Vous découvrirez les branches, observerez cette collision, modifierez leurs Jenkinsfiles et publierez deux aperçus utilisables. Vous changerez ensuite une heure de rendez-vous et confirmerez que son aperçu est mis à jour tandis que l’autre proposition reste intacte.
Les prérequis sont la saisie de base dans un terminal, les chemins, la navigation dans Jenkins et la reconnaissance d’un court Pipeline déclaratif. Les branches Git, les commits, le push, l’indexation et les nouveaux paramètres du Pipeline sont expliqués avant utilisation. Le dépôt, le programme de construction Java, le mécanisme de publication et les plugins Jenkins sont préparés ; vous ne les installez pas et n’écrivez pas le site web. Il s’agit d’un service source et d’aperçu local de formation sur une seule machine virtuelle, et non de GitHub ou 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.
Découvrir les propositions et leurs builds de branche
Dans cette étape, vous examinerez les programmes normaux et les sources candidates, puis découvrirez leurs jobs de branche et observerez la collision de l’aperçu partagé. Commencez dans Preview Desk.
Choisissez Open the official program. Confirmez Common Ground Day et 09:30. Choisissez Explore this plan et vérifiez les trois activités et l’illustration du parcours. Choisissez Download the activities pour obtenir un véritable CSV et Read visitor notes pour le texte complet. Utilisez l’action Back du navigateur pour revenir à la vue d’ensemble, puis de nouveau Back pour revenir au bureau. Ouvrez également Read the courtyard notes et confirmez Courtyard Stories. Les deux programmes existants doivent rester disponibles tout au long de votre travail.
Passez à Source. Ce terminal est une copie de travail Git : les fichiers que vous pouvez modifier appartiennent à une seule branche sélectionnée à la fois. Une branche est une ligne d’historique source nommée. Changer de branche remplace les fichiers de travail par la version de cette branche ; cela ne modifie pas l’autre branche. Un commit est une version enregistrée du contenu du dépôt, identifiée par une empreinte de hachage ; cet identifiant reliera un build Jenkins à sa source.
Le terminal s’ouvre dans /home/labex/project/community-site. pwd affiche le répertoire actuel. git --no-pager branch --list liste les branches locales, avec * devant celle qui est sélectionnée. --no-pager garde le résultat directement dans le terminal. Sans cette option, Git peut ouvrir un lecteur interactif ; si vous voyez (END) au lieu d’une invite de commande, appuyez sur q pour quitter le lecteur. Exécutez :
pwd
git --no-pager branch --list
La liste comprend main, courtyard-notes, garden-plan et river-plan. La sélection préparée est garden-plan. Si vous changez de répertoire par erreur, revenez avec cd /home/labex/project/community-site avant de continuer.
cat affiche un fichier sans le modifier. event.properties stocke un paramètre key=value par ligne pour le titre, les détails du rendez-vous et les activités. Lisez ce petit fichier de données :
cat event.properties
Il décrit Garden Gathering, avec un rendez-vous à 10:00 près de Glasshouse gate. La ligne meeting_time est une donnée utilisée par le programme de construction fourni, qui produit ensemble les pages, le CSV et les notes.
git switch sélectionne une branche dans cette copie de travail. Comparez la seconde proposition, puis revenez :
git switch river-plan
cat event.properties
git switch garden-plan
La seconde proposition est Riverside Picnic, avec un rendez-vous à 14:00 près de River steps. Ce sont des fichiers sources réellement différents, et non une seule page portant un autre badge de branche.
Votre périmètre de modification se limite au Jenkinsfile des branches candidates et au changement de meeting_time demandé plus tard dans event.properties. Gardez les modèles, l’image du parcours, le programme de construction et le mécanisme de publication inchangés. Ne modifiez, supprimez, renommez ou recréez ni le projet Jenkins préparé ni les jobs de branche. Préservez tous les historiques Git et Jenkins ainsi que chaque archive d’aperçu conservée, les branches main et courtyard-notes, le programme officiel et l’aperçu de la cour. Cet exercice ne nécessite ni Docker ni commandes d’administration.
À ce stade, identifiez quelle proposition commence à 10:00 et laquelle commence à 14:00. Aucun aperçu candidat n’a encore été publié.
Lancez maintenant la découverte native des branches dans Jenkins et comparez les builds réussis à leur résultat réel de publication. Passez à Jenkins et ouvrez community-previews depuis Dashboard.
Ce parent préparé est un Multibranch Pipeline. Il analyse un dépôt Git à la recherche de branches contenant un Jenkinsfile et crée un job Pipeline enfant pour chacune. La source utilise un petit service Git en lecture seule dans cet environnement de formation ; l’origin préparé de la copie de travail est le dépôt où vos futurs push publieront les changements de source. Aucun compte externe ni identifiant de connexion n’est nécessaire.
Attendez la fin du chargement de la page Jenkins, puis choisissez Scan Multibranch Pipeline Now. Ouvrez Scan Multibranch Pipeline Log et attendez Finished: SUCCESS. L’analyse découvre garden-plan et river-plan ; main et courtyard-notes ne contiennent pas de Jenkinsfile et ne sont pas des jobs candidats. Revenez par le lien community-previews du fil d’Ariane. Attendez la fin des deux builds enfants.
Ouvrez garden-plan, puis son build numéroté et Console Output. Sa sortie doit identifier Garden Gathering, 10:00 et la révision source extraite. Revenez par community-previews, ouvrez river-plan et examinez la console de son build numéroté. Elle doit identifier Riverside Picnic, 14:00 et sa propre révision source. Les deux doivent se terminer par SUCCESS. Dans cet environnement préparé, un message d’outil Git Using Default peut apparaître avant une extraction réussie ; lisez la révision réelle et le résultat final pour déterminer si l’extraction a abouti.
Passez à Source. Lisez le Pipeline fourni :
cat Jenkinsfile
options { skipDefaultCheckout() } désactive l’extraction implicite des sources du Pipeline déclaratif pour que l’étape visible Check out this branch l’effectue explicitement. checkout scm utilise la révision précise de la branche qui a fourni ce Jenkinsfile. Ne la remplacez pas par une extraction d’une branche fixe.
L’étape Build preview fournie transforme cette source extraite en véritables fichiers visiteurs. Archive preview conserve preview.zip dans Jenkins avant que Publish preview envoie ces mêmes octets au bureau local. Le bloc final post utilise deleteDir() pour vider l’espace de travail de ce build. Conservez ces étapes et le nettoyage.
Un bloc environment fournit des valeurs aux étapes. Les deux branches contiennent actuellement ce même paramètre :
PREVIEW_KEY = 'shared'
PREVIEW_KEY choisit l’adresse de publication sur le bureau. La chaîne littérale 'shared' envoie les deux builds au même emplacement, même si leurs extractions de source sont différentes. Revenez à Preview Desk et actualisez la page. Il y a une seule carte candidate shared, qui affiche la branche publiée en dernier. Choisissez son lien Open preview et comparez son titre aux deux builds sources réussis. Vous ne pouvez pas partager deux aperçus indépendants depuis cette seule adresse.
Utilisez l’action Back du navigateur pour revenir au bureau. Le programme officiel et les notes de la cour doivent toujours fonctionner. Vous avez maintenant observé pourquoi des jobs de branche distincts n’impliquent pas automatiquement des résultats publiés distincts.
Donner à chaque branche son propre aperçu
Dans cette étape, vous modifierez et publierez le Jenkinsfile de chaque branche, puis construirez les deux aperçus indépendants. Commencez dans Source, dans /home/labex/project/community-site.
Jenkins fournit env.BRANCH_NAME dans un build Multibranch. Il s’agit du nom de la branche actuelle, par exemple garden-plan. Remplacez la valeur partagée par cette identité native de branche :
PREVIEW_KEY = "${env.BRANCH_NAME}"
Les guillemets doubles Groovy permettent à ${...} d’insérer la valeur de la variable. Des apostrophes autour de cette expression conserveraient ses caractères littéraux. Les noms de branche de cet exercice utilisent déjà de simples lettres minuscules et des traits d’union adaptés aux adresses d’aperçu ; ce n’est pas une règle générale de normalisation pour des noms de branche arbitraires.
Sélectionnez d’abord la proposition du jardin. git status --short affiche les modifications non enregistrées dans un commit sous une forme compacte ; M signifie qu’un fichier est modifié, et l’absence de sortie signifie que la copie de travail est propre. nano est un éditeur de terminal pour le fichier nommé ; il garde le contrôle de ce terminal jusqu’à ce que vous enregistriez et quittiez.
git switch garden-plan
git status --short
nano Jenkinsfile
nano modifie le fichier nommé dans ce terminal. Utilisez les touches fléchées pour atteindre la ligne PREVIEW_KEY. Appuyez sur Home pour aller à son début, puis une seule fois sur Ctrl+K pour couper cette ligne. Saisissez la ligne de remplacement complète indiquée ci-dessus, y compris son indentation, et appuyez sur Enter pour garder la ligne RECEIVER_URL suivante séparée. Ne coupez pas d’autres lignes. Enregistrez avec Ctrl+O, appuyez sur Enter pour confirmer Jenkinsfile, puis quittez avec Ctrl+X. Ici, Ctrl signifie maintenir la touche Control, y compris sur macOS.
Examinez votre modification avant de l’enregistrer dans l’historique Git. git diff compare le fichier de travail à sa version enregistrée dans un commit. Comme précédemment, --no-pager affiche directement le résultat dans le terminal ; -- sépare les options du chemin du fichier. Exécutez :
git --no-pager diff -- Jenkinsfile
Le diff doit montrer uniquement la suppression de l’ancienne ligne PREVIEW_KEY et l’ajout de la nouvelle. Les préfixes - et + décrivent le texte supprimé et ajouté ; ce ne sont pas des caractères à saisir dans le fichier. Si le diff contient une modification involontaire, rouvrez nano Jenkinsfile, corrigez-la, enregistrez, quittez et examinez de nouveau le résultat. Si vous voyez une erreur de fichier introuvable, exécutez pwd et revenez au répertoire de travail indiqué ci-dessus.
Un commit enregistre le changement de source indexé sur la branche sélectionnée. git add indexe ce fichier ; git commit -m l’enregistre avec le message fourni ; git push origin garden-plan publie cette branche dans le dépôt origin préparé pour que Jenkins puisse découvrir le nouveau commit. Dans ces commandes de commit, les guillemets doubles gardent le message de plusieurs mots dans un seul argument. Ces commandes modifient l’historique source, sans modifier directement l’aperçu en cours :
git add Jenkinsfile
git commit -m "Give the garden plan its own preview"
git push origin garden-plan
Appliquez maintenant le même paramètre à l’autre proposition :
git switch river-plan
git status --short
nano Jenkinsfile
Remplacez uniquement sa ligne PREVIEW_KEY avec la même opération dans nano et la même expression exacte entre guillemets doubles. Enregistrez et quittez. Examinez, enregistrez dans un commit et poussez cette branche :
git --no-pager diff -- Jenkinsfile
git add Jenkinsfile
git commit -m "Give the river plan its own preview"
git push origin river-plan
Si Git refuse de changer de branche à cause de modifications non enregistrées dans un commit, exécutez git status --short et examinez d’abord le diff sur la branche actuelle. Terminez ou corrigez cette modification prévue avant de changer de branche ; ne supprimez pas les modifications des fichiers et ne réinitialisez pas le dépôt. Si git commit indique qu’il n’y a rien à enregistrer alors que vous avez déjà créé le commit prévu, examinez git --no-pager log -1 --oneline et poursuivez avec le push de la branche. -1 limite cette vue à un commit ; --oneline affiche son identifiant court et son message.
Passez à Jenkins, revenez à community-previews avec le fil d’Ariane et choisissez de nouveau Scan Multibranch Pipeline Now. Cet exercice local n’utilise pas de webhook : pousser les sources ne demande donc pas à lui seul une analyse. Attendez que l’analyse et les deux nouveaux builds enfants se terminent avec succès. Chaque console doit montrer sa propre clé d’aperçu de branche. Si un build signale une erreur de syntaxe Groovy, corrigez les guillemets et les accolades de son Jenkinsfile dans Source, enregistrez et poussez la correction sur cette branche, puis relancez l’analyse. Ne modifiez pas un job enfant généré à la place de sa source.
Passez à Preview Desk et actualisez la page. Il doit maintenant y avoir des cartes garden-plan et river-plan distinctes. L’ancienne carte partagée peut rester comme résultat observé précédemment. Ouvrez le lien Open preview de chaque proposition et vérifiez son titre, son heure de rendez-vous, ses trois activités, l’image du parcours, le CSV et les notes pour les visiteurs. Après avoir exploré une proposition, utilisez l’action Back du navigateur pour revenir à sa vue d’ensemble, puis de nouveau Back pour revenir au bureau avant d’ouvrir l’autre carte. Les deux adresses d’aperçu doivent être différentes et rester utilisables simultanément.
Repérez les clés garden-plan et river-plan au-dessus de leurs propres titres et heures de rendez-vous d’origine. La carte shared conservée montre la collision antérieure ; elle ne remplace aucun des deux aperçus indépendants.
Dans Jenkins, ouvrez la page d’état du dernier build réussi de chaque branche et téléchargez preview.zip depuis Build Artifacts. Extrayez chaque ZIP dans un nouveau dossier différent et ouvrez index.html. Gardez les sept fichiers ensemble. Les pages et pièces jointes doivent fonctionner localement ; une pièce jointe texte peut s’ouvrir directement plutôt que de déclencher un nouveau téléchargement. build.json identifie la branche source et le commit réels. Ces aperçus complets constituent le résultat ; deux libellés de build verts ne suffisent pas.
Mettre à jour une proposition et préserver l’autre
Dans cette étape, vous changerez l’heure de rendez-vous du jardin et utiliserez une nouvelle analyse pour mettre à jour uniquement l’aperçu de cette branche. Commencez dans Jenkins et notez le numéro du dernier build réussi de river-plan. Gardez son aperçu ouvert pour comparer.
Passez à Source. Sélectionnez la branche du jardin et modifiez son petit fichier de données :
git switch garden-plan
git status --short
nano event.properties
Remplacez uniquement la ligne complète meeting_time de meeting_time=10:00 par :
meeting_time=10:30
Utilisez la même opération que pour la ligne du Pipeline : touches fléchées, Home, un seul Ctrl+K, texte de remplacement et Enter. Enregistrez avec Ctrl+O, Enter, puis quittez avec Ctrl+X. Le programme de construction lit cette unique valeur pour garder la page, le CSV et les notes cohérents ; vous ne modifiez pas les fichiers visiteurs générés.
Examinez et publiez cette mise à jour de source :
git --no-pager diff -- event.properties
git add event.properties
git commit -m "Move the garden meeting to 10:30"
git push origin garden-plan
Le diff doit modifier uniquement cette heure de rendez-vous. Sinon, corrigez le fichier avant de créer le commit. La branche de la rivière ne reçoit aucun changement de source.
Passez à Jenkins, revenez à community-previews et choisissez Scan Multibranch Pipeline Now. Après l’indexation, le job du jardin doit lancer un nouveau build pour sa révision modifiée ; la branche inchangée de la rivière doit conserver le numéro de build que vous avez noté. Attendez que le build du jardin se termine par SUCCESS. Ouvrez Console Output et reliez le nouveau commit et 10:30 au changement de source.
Si l’analyse indique qu’il n’y a aucun changement et que l’aperçu du jardin reste ancien, revenez à Source. Vérifiez git status --short et git --no-pager log -1 --oneline, confirmez que le changement prévu a été enregistré dans un commit sur garden-plan et poussez cette branche avant de relancer l’analyse. Une modification locale ou un commit qui n’a pas atteint origin n’est pas encore une source que Jenkins peut découvrir. Si un build échoue, lisez sa console et corrigez l’erreur source indiquée avec un nouveau commit et un push. Ne réinitialisez pas la machine virtuelle et ne remplacez pas le programme de construction fourni.
Passez à Preview Desk et actualisez la page. Ouvrez garden-plan : Garden Gathering doit maintenant commencer à 10:30. Examinez Explore this plan, le CSV des activités téléchargé et les notes complètes pour les visiteurs ; l’heure de rendez-vous doit concorder partout. Ouvrez river-plan : Riverside Picnic doit toujours commencer à 14:00, avec ses activités d’origine et ses pièces jointes fonctionnelles. Son build.json doit conserver le commit source précédent et le numéro de build natif. Ne relancez pas ce job enfant inchangé pendant cette mise à jour finale.
Revenez à Jenkins et téléchargez le dernier preview.zip du jardin. Extrayez-le dans un autre nouveau dossier et répétez les vérifications locales des pages, de l’image, du CSV et des notes. Il doit identifier le nouveau commit du jardin ; le dossier de la rivière téléchargé précédemment doit toujours être utilisable indépendamment.
Enfin, revenez à Preview Desk, ouvrez Open the official program et Read the courtyard notes, et confirmez que les deux programmes complets restent intacts. Préservez les historiques d’origine des branches et des builds. Si vous modifiez encore une source, créez un commit, poussez-le et terminez le build Jenkins correspondant avant de vérifier que le travail est terminé. Vous disposez de deux aperçus actifs et de preuves que la mise à jour de l’un n’a ni écrasé ni reconstruit son voisin.
Résumé
Vous avez utilisé la découverte native Multibranch et la révision source de chaque Jenkinsfile, puis séparé les publications grâce à l’identité de branche fournie par Jenkins. Les deux propositions disposent désormais de pages, d’images et de pièces jointes utilisables à des adresses indépendantes. Un commit ultérieur du jardin a mis à jour uniquement son propre aperçu, tandis que le build de la rivière, le programme officiel et l’aperçu de la cour sont restés intacts.
