Share
Dans cette deuxième et dernière partie de la série, nous examinerons le plug-in Jenkins Workflow comme solution pour la configuration de pipelines Jenkins plus complexes..
Nous reprendrons la première partie de la série. Dans la première partie, Jeff Reifman vous a expliqué comment configurer une instance Jenkins sur Digital Ocean et créer votre première version de Jenkins. Si vous ne l'avez pas encore lu, je suggère de le faire avant de continuer. C'est bon, je vais attendre. Je peux être très patient…
… Tous pris? Génial! Faisons cela.
Jenkins Workflow est un plugin pour Jenkins. Une fois installé, un nouveau type d'élément devient disponible: un «workflow». Les projets de flux de travail peuvent être utilisés aux mêmes fins que les projets Jenkins «Freestyle» habituels, mais ils peuvent également orchestrer des tâches beaucoup plus volumineuses pouvant couvrir plusieurs projets, voire même créer et gérer plusieurs espaces de travail dans un seul flux de travail. De plus, toute cette gestion peut être organisée en un seul script, plutôt que répartie sur un ensemble de configurations, de projets et d'étapes..
Avant de pouvoir créer des flux de travail, nous devons installer le plug-in Jenkins Workflow. Dans le tableau de bord Jenkins, cliquez sur Gérer Jenkins, puis Gérer les plugins. Basculer vers le Disponible onglet et recherchez «Workflow».
Cochez la case pour Plugin de workflow, puis Installer sans redémarrer.
Maintenant, voici le piège. Il existe plusieurs plug-ins nommés «Plug-in de flux de travail». Vous devrez donc répéter les étapes ci-dessus plusieurs fois. Vous pouvez également cliquer sur les cases à cocher multiples ou installer le plug-in Workflow Aggregator..
Une fois que «plug-in de flux de travail» ne figure plus dans la liste des plug-ins disponibles, redémarrez Jenkins en accédant à /redémarrer et en cliquant Oui.
Faisons mouiller nos flux de travail. Nous allons prendre le projet que Jeff a mis en place dans la première partie et le construire en tant que workflow.
Pour commencer, allez au tableau de bord Jenkins et cliquez sur Nouvel article. Nommez le nouvel élément "Shell Test (Workflow)", puis sélectionnez le Flux de travail type.
Cliquez sur D'accord pour créer le nouveau projet. Vous allez atterrir sur la page de configuration du projet.
Vous remarquerez que les options de configuration diffèrent des projets Jenkins standard. Il n'y a plus aucune option pour ajouter un référentiel GitHub, des étapes de construction ou des actions post-construction. Au lieu de cela, il y a une nouvelle section appelée Flux de travail.
Dans la section Workflow se trouve une zone de texte intitulée Scénario. C'est là que vous allez définir le script de flux de travail que Jenkins exécutera lorsqu'il initialisera la construction du projet..
“Quel type de script?” Vous demandez. Excellente question. Le plug-in Jenkins Workflow utilise un langage appelé Groovy pour ses scripts. Groovy est un langage de script polyvalent pour la machine virtuelle Java. Ne vous inquiétez pas, vous n'avez pas vraiment besoin de connaître Groovy ou Java pour que tout fonctionne, le plug-in Jenkins Workflow utilise un petit DSL au-dessus de Groovy et il est très facile de combiner des commandes pour créer le flux de travail de votre projet.
Allez-y et ajoutez ce qui suit dans la boîte de script:
noeud java git 'https://github.com/redhotvengeance/hello-jenkins.git' sh 'uptime'
Alors qu'est-ce qui se passe ici?
Tout d'abord, nous ouvrons un nœud bloc. Les nœuds sont où les actions de workflow se produisent. Lorsque vous allouez un nœud, un nouvel espace de travail (un contexte / dossier) est créé. Tout le code dans le nœud le bloc s'exécute dans cet espace de travail. Cela permet de s'assurer que les étapes de construction ne se polluent pas.
Ensuite, nous lançons une commande Git avec git 'https://github.com/redhotvengeance/hello-jenkins.git'. Cette commande clone le dépôt Git dans notre espace de travail..
Enfin, nous demandons à Workflow d’exécuter le la disponibilité commande shell avec sh 'disponibilité'.
Cliquez sur sauvegarder, et vous serez redirigé vers la page de destination du projet. Dans le menu de gauche, un bouton intitulé Construire maintenant. Cliquez dessus pour lancer une construction.
Une fois la construction terminée, cliquez sur build #1 trouvé dans le Construire l'histoire section. Puis clique Sortie de la console dans le menu de gauche.
Ici, nous pouvons voir tout ce qui est enregistré pendant l'exécution de la construction. Cela a commencé par l'allocation d'un noeud dans l'espace de travail «Shell Test (Workflow)». Ensuite, il a récupéré le dépôt Git. Enfin, il a exécuté le la disponibilité script shell, qui a imprimé les statistiques de disponibilité du serveur.
Et c'est tout! Nous avons maintenant recréé les mêmes étapes que la configuration de projet Jenkins normale dans la première partie, sauf que cette fois est un workflow. Maintenant, utilisons ces mêmes concepts pour faire quelque chose d'un peu plus complexe.
Avant de pouvoir créer notre flux de travail complexe, nous avons besoin du travail qui le traversera. Faux projets à la rescousse!
Comme nous utilisons déjà Groovy pour la programmation de notre flux de travail, utilisons Gradle pour nos faux projets. Gradle est un système de construction qui utilise Groovy (surprenant, je sais!). Pour utiliser Gradle, nous devrons l'installer sur notre serveur. SSH sur votre serveur (consultez la première partie de Jeff si vous avez besoin d’actualiser votre mémoire) et exécutez:
shell sudo apt-get install gradle
Nous sommes prêts à partir.
Nous utiliserons deux pensions dans notre nouveau flux de travail. Le premier est le constructeur. Notre projet de construction est très simple: il contient un script de construction Gradle avec le code suivant:
tâche groovy createBuild << new File("built.txt").write("You cannot pass.\n")
Alors qu'est-ce qui se passe ici? Gradle fonctionne en exécutant des «tâches» et le script de génération de Gradle définit ces tâches. Nous avons défini une tâche appelée createBuild, et ce qu'il fait est de créer un fichier texte appelé construit.txt avec le contenu:
Tu ne peux pas passer.
C'est tout. (Eh bien, je fait dis c'était simple!)
Le deuxième dépôt Git est notre emballeur. Le conditionneur a également un script de construction Gradle, mais il est un peu plus complexe:
tâche groovy createPackage << String packageText = "I am a servant of the Secret Fire, wielder of the flame of Anor. You cannot pass. The dark fire will not avail you, flame of Udûn. Go back to the Shadow!" String builtText = new File('built.txt').text new File("package.txt").write(packageText + "\n\n" + builtText)
le createPackage Cette tâche crée également un fichier texte (appelé package.txt), mais il compte utiliser le contenu de construit.txt, qui n'existe pas dans le référentiel du conditionneur. Si construit.txt existait dans le repo, le généré package.txt contiendrait:
Je suis un serviteur du feu secret, un détenteur de la flamme d'Anor. Tu ne peux pas passer. Le feu noir ne vous sera d'aucun secours, flamme d'Udûn. Retourne à l'ombre!
Tu ne peux pas passer.
Si construit.txt est manquant, notre createPackage tâche va jeter une erreur.
Donc, chaque fois que nous construisons notre emballeur, nous devons d’abord exécuter notre constructeur et faire en sorte que construit.txt disponible pour le conditionneur afin qu'il puisse créer package.txt.
Et c'est exactement ce que nous allons mettre en place un flux de travail Jenkins à faire!
Dirigez-vous vers le tableau de bord Jenkins, cliquez sur Nouvel article, nommez-le "assembleur", sélectionnez Flux de travail, et cliquez D'accord.
Commençons le script. Tout d'abord, nous allons ouvrir un nœud bloquer, comme avant:
"noeud java
"
Ensuite, clonons notre rapport de constructeur:
noeud java git 'https://github.com/redhotvengeance/jenkins-workflow-build.git'
Nous devons maintenant exécuter notre script de génération Gradle pour générer le construit.txt fichier:
noeud java git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild'
Enfin, assurons-nous que tout fonctionne comme prévu. Nous allons ajouter un chat pour imprimer le contenu de la construit.txt fichier:
noeud java git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'cat ./built.txt'
Cliquez sur sauvegarder, et ensuite commencer une construction. Une fois que c'est fait, jetez un coup d'œil au Sortie de la console.
Excellent! Nous clonons avec succès le repo, exécutant le createBuild tâche et ont confirmé que le contenu de construit.txt est Tu ne peux pas passer.. Passons maintenant au conditionneur.
Comme avec le constructeur, nous devons cloner notre référentiel de conditionneur. Ajoutons le code du conditionneur:
"noeud java git 'https://github.com/redhotvengeance/jenkins-workflow-build.git' sh 'gradle createBuild' sh 'cat ./built.txt'
noeud git 'https://github.com/redhotvengeance/jenkins-workflow-package.git' sh 'crée un packagePackage' sh 'cat ./package.txt' "
Puisque nous n’avons pas créé explicitement un nouvel espace de travail, le createPackage la tâche sera exécutée dans le même espace de travail que le createBuild tâche, ce qui signifie que le construit.txt fichier que le conditionneur attend sera disponible pour lui.
Allez-y et sauvegarder et Construire maintenant, puis voir le Sortie de la console.
Tout a fonctionné comme prévu: notre constructeur a été cloné et a couru, et notre emballeur a été cloné et a couru. Et si nous regardons la sortie, la voilà! Le Balrog de Morgoth a été pleinement Gandalf'd.
Artificiel? Très certainement.
Mais un concept complexe n’est en réalité qu’un ensemble de concepts simples mélangés. En surface, nous avons rassemblé le discours de Gandalf sur le pont de Khazad-dûm. Mais en réalité, nous avons pris la production d’un projet et l’injecté dans la production d’un autre projet..
Et si au lieu du dialogue de Gandalf, les sorties étaient des exécutables de bases de code distinctes qui devaient toutes être assemblées pour le logiciel que vous livrez? Vous utiliseriez le même flux de travail que celui que nous avons défini ici: clonage, construction, copie et conditionnement. Avec le plugin Jenkins Workflow, il ne vous fallait que quelques lignes de Groovy. Et en bonus, tout est contenu dans un seul script!
Il existe également d'autres outils disponibles pour vous aider à gérer et à visualiser un flux de travail Jenkins. CloudBees offre une fonctionnalité de visualisation de la phase de flux de travail sur leur plate-forme d'entreprise Jenkins.
Cela ne fait qu'effleurer la surface de ce qui peut être fait avec le plugin Jenkins Workflow. Assurez-vous de consulter les liens ci-dessous pour en savoir plus..
Bonne chance pour votre travail fluide!
Accentsconagua