TOC

Comment configurer des pipelines d’intégration continue avec Concourse CI sur Ubuntu 16.04

introduction

Concourse CI est un système d’intégration continue moderne et évolutif, conçu pour automatiser les pipelines de test avec une syntaxe déclarable composable. Dans les guides précédents, nous installed Concourse sur un serveur Ubuntu 16.04 et https: // www.digitalocean.com/community/tutorials/how-to-secure-concourse-ci-with-ssl-using-nginx-on-ubuntu-16-04[sécurisé l’interface utilisateur Web avec un certificat SSL de Let’s Encrypt].

Dans ce guide, nous montrerons comment utiliser Concourse pour exécuter automatiquement la suite de tests de votre projet lorsque de nouvelles modifications sont validées dans le référentiel. Pour démontrer, nous allons configurer un pipeline d’intégration continue pour une application «hello world» écrite avec Hapi.js, une infrastructure Web Node.js.

Pour vous assurer que les procédures de construction et de test sont toujours synchronisées avec le code auquel elles sont associées, nous allons ajouter les définitions de CI au référentiel d’application lui-même. Ensuite, nous utiliserons l’outil de ligne de commande + fly + de Concourse pour charger le pipeline dans Concourse. Enfin, nous allons transférer nos modifications dans le référentiel afin de les enregistrer de manière plus permanente et de lancer un nouveau test dans le nouveau flux de travail CI.

Conditions préalables

Avant de commencer, vous aurez besoin d’un serveur Ubuntu 16.04 * avec au moins 1 Go de RAM *. Complétez les guides suivants pour configurer un utilisateur non root, installer et configurer Concourse, installer Nginx, obtenir un certificat TLS / SSL et configurer un proxy inverse sécurisé pour l’interface utilisateur Web de Concourse. Vous aurez besoin d’un * nom de domaine * indiqué sur votre serveur Concourse pour le sécuriser correctement:

Dans ce tutoriel, la plupart du travail sera effectué sur votre ordinateur local plutôt que sur le serveur Concourse. En tant que tel, vous devrez également vous assurer que quelques outils sont disponibles sur votre ordinateur local. Vous aurez besoin d’un éditeur de texte (les exemples + nano +, + vim +, TextEdit, Sublime Text, Atom ou Notepad, que vous rencontrerez sur différents systèmes d’exploitation) vous permettent de créer et de modifier des fichiers dans le référentiel. Vous devrez également installer et configurer Git sur votre système local, ce que vous pouvez faire en suivant notre https://www.digitalocean.com/community/tutorials/contributing-to-open-source-getting-started-with- Guide de git [Contribuer à Open Source: Premiers pas avec Git].

Une fois que vous avez configuré votre serveur Concourse et installé Git et un éditeur de texte sur votre ordinateur local, continuez ci-dessous.

Installation locale de l’outil de ligne de commande Fly

Lorsque nous avons installé Concourse sur le serveur dans les conditions préalables, nous avons installé l’outil de ligne de commande + fly + sur le serveur afin de pouvoir gérer l’instance de Concourse à partir de la ligne de commande. Cependant, pour une utilisation quotidienne, il est plus pratique d’installer une copie du binaire + fly + sur votre système local, où vos outils de développement et votre code source habituels sont disponibles.

Pour obtenir une copie locale de + fly + correspondant à la version de votre serveur, visitez votre instance Concourse dans votre navigateur Web:

https://

Si vous êtes déconnecté ou si aucun pipeline n’est actuellement configuré, les liens pour télécharger + fly + pour différentes plates-formes seront affichés au centre de la fenêtre:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/big_download_link.png [Lien de téléchargement volumineux de la volée]

Si vous êtes connecté et qu’un pipeline est configuré, les liens de téléchargement pour + fly + seront disponibles dans le coin inférieur droit de l’écran:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/small_download_link.png [lien de téléchargement de la petite volée]

Cliquez sur l’icône représentant le système d’exploitation de votre ordinateur local pour télécharger le binaire + fly +.

Suivez ensuite les instructions spécifiques à la plate-forme pour configurer + fly + sur votre système local.

Linux ou macOS

Si votre ordinateur local exécute Linux ou macOS, suivez ces instructions après avoir téléchargé le binaire approprié.

Commencez par marquer le fichier binaire téléchargé comme exécutable. Nous supposerons que vous avez téléchargé le fichier dans votre répertoire + ~ / / Téléchargements +, ajustez l’emplacement de téléchargement si nécessaire:

chmod +x ~/Downloads/fly

Ensuite, installez le binaire à un emplacement de votre PATH en tapant:

sudo install ~/Downloads/fly /usr/local/bin

Vous pouvez vérifier que l’exécutable est disponible en tapant:

fly --version
Output3.3.1

Si vous êtes capable d’afficher la version, + fly + a été installé avec succès.

les fenêtres

Si votre ordinateur local fonctionne sous Windows, appuyez sur la touche * Windows * de votre clavier, tapez * powershell *, puis appuyez sur * Entrée *.

Dans la fenêtre qui apparaît, créez un dossier + bin + en tapant:

mkdir bin

Ensuite, déplacez le fichier + fly.exe + de votre dossier + Téléchargements vers le nouveau dossier` + bin` en tapant:

mv Downloads/fly.exe bin

Vérifiez si vous avez déjà un profil PowerShell disponible:

Test-Path $profile

Si la réponse est + True +, vous avez déjà un profil.

Si la réponse est + False +, vous devrez en créer une en tapant:

New-Item -path $profile -type file -force
Output
   Directory: C:\User\Sammy\Documents\WindowsPowerShell

Mode              LastWriteTime       Length Name
----              -------------       ------ ----
-a----       7/9/2017   5:46 PM            0 Microsoft.PowerShell_profile.ps1

Une fois que vous avez un profil, éditez-le avec votre éditeur:

notepad.exe $profile

Dans la fenêtre de l’éditeur (qui sera vide si vous deviez créer votre profil), ajoutez la ligne suivante:

Microsoft.PowerShell_profile.ps1

$env:path += ";C:\Users\Sammy\bin"

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, définissez la stratégie d’exécution sur «RemoteSigned» pour que l’utilisateur actuel permette à PowerShell de lire le profil:

Set-ExecutionPolicy -scope CurrentUser RemoteSigned

Enfin, recherchez le profil PowerShell en tapant:

. $profile

Vous devriez maintenant pouvoir appeler l’exécutable + fly.exe + depuis n’importe quel emplacement. Testez ceci en faisant en sorte que le binaire imprime sa version:

fly.exe --version
Output3.3.1

Tout au long de ce guide, vous devrez remplacer chaque instance de la commande + fly + par + fly.exe + pour correspondre à la commande Windows.

Authentification avec le serveur Concourse

Après avoir installé + fly +, connectez-vous à votre serveur Concourse distant afin de pouvoir gérer votre environnement de CI localement. Un seul binaire + fly + peut être utilisé pour contacter et gérer plusieurs serveurs Concourse. La commande utilise donc un concept appelé «cibles» en tant qu’étiquette pour identifier le serveur auquel vous voulez envoyer des commandes.

Nous utilisons * main * comme nom de cible pour notre serveur Concourse dans ce guide, mais vous pouvez remplacer le nom de cible de votre choix. Entrez le nom de domaine de votre serveur Concourse avec les spécifications de protocole + https: // + après l’option + -c + pour indiquer l’emplacement de votre serveur:

fly -t main login -c https://

Vous serez invité à entrer le nom d’utilisateur et le mot de passe que vous avez configurés dans le fichier + / etc / concourse / web_environment + sur le serveur Concourse:

Outputlogging in to team 'main'

username: sammy
password:

target saved

Une fois que vous vous êtes authentifié, l’outil + fly + créera un fichier de configuration appelé + ~ / .flyrc + pour stocker vos informations d’identité pour les commandes futures.

Forking et clonage du référentiel d’exemples

Maintenant que vous avez paramétré `+ fly + 'sur votre système, nous pouvons passer à la configuration du référentiel que nous utiliserons pour illustrer les pipelines de Concourse.

Dans votre navigateur Web, visitez l’application hhello hapi sur GitHub, que nous allons utiliser comme exemple. Cette application est un programme simple "hello world" avec quelques tests unitaires et d’intégration, écrit avec Hapi.js, un framework Web Node.js.

Comme cet exemple est utilisé pour illustrer divers systèmes d’intégration continue, vous remarquerez peut-être que certains fichiers sont utilisés pour définir des pipelines pour d’autres systèmes. Pour Concourse, nous allons créer le pipeline d’intégration continue dans notre propre branche du référentiel.

Pour créer votre branche du référentiel, connectez-vous à GitHub et accédez au référentiel https://github.com/do-community/hello_hapi. Cliquez sur le bouton * Fourchette * dans le coin supérieur droit pour créer une copie du référentiel de votre compte:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/fork_repository.png [bonjour référentiel de fourche hapi]

Si vous êtes membre d’une organisation GitHub, on vous demandera peut-être où vous souhaitez ouvrir le référentiel. Une fois que vous avez sélectionné un compte ou une organisation, une copie du référentiel sera ajoutée à votre compte.

Ensuite, dans un terminal de votre ordinateur local, accédez à votre répertoire personnel:

cd $HOME

Clonez le référentiel sur votre ordinateur local à l’aide de la commande suivante, en remplaçant votre propre nom d’utilisateur GitHub:

git clone [email protected]:/hello_hapi

Un nouveau répertoire appelé + hello_hapi + sera créé dans votre répertoire personnel. Entrez le nouveau répertoire pour commencer:

cd hello_hapi

Nous définirons un pipeline d’intégration continue pour l’exemple de projet à l’intérieur de ce référentiel. Avant d’apporter des modifications, il est judicieux de créer une nouvelle branche dans Git et d’en changer pour isoler nos modifications:

git checkout -b pipeline
OutputSwitched to a new branch 'pipeline'

Maintenant que nous avons une nouvelle branche dans laquelle travailler, nous pouvons commencer à définir notre pipeline d’intégration continue.

Définition du processus d’intégration continue pour l’application

Nous définirons notre pipeline et tous ses fichiers associés dans le référentiel du projet lui-même. Cela permet de garantir que les processus d’intégration continue sont toujours synchronisés avec le code qu’il teste.

La suite de tests est déjà définie dans un répertoire appelé + test +. Il comprend un test unitaire et deux tests d’intégration de base. La commande pour exécuter les tests est définie dans le fichier + package.json sous le nom` + test` dans l’objet + script. Dans un environnement où + npm + et Node.js sont installés, vous pouvez exécuter les tests en tapant + npm test + (après avoir installé les dépendances du projet avec + npm install +). Ce sont les procédures que nous devrons reproduire dans notre pipeline.

Pour commencer, créez un répertoire appelé + ci + dans le référentiel pour héberger les actifs d’intégration continue du projet. Nous allons également créer deux sous-répertoires appelés + ci / tasks + et + ci / scripts + pour contenir les définitions de tâches individuelles référencées par le pipeline et les scripts appelés par les tâches.

Créez la structure de répertoire nécessaire en tapant:

mkdir -p ci/{tasks,scripts}

Ensuite, nous pouvons commencer à créer les fichiers individuels que Concourse utilisera.

Définir le pipeline

Créez et ouvrez un fichier nommé + pipeline.yml + dans le répertoire + ci + avec votre éditeur de texte (nous montrerons l’éditeur + nano + dans ce guide, mais vous devez remplacer l’éditeur de texte par votre système). Comme l’extension l’indique, les fichiers Concourse sont définis à l’aide du format de sérialisation des données YAML:

nano ci/pipeline.yml

Nous pouvons maintenant commencer à installer notre pipeline.

Définir le type de ressource du cache NPM

Dans le fichier, nous allons commencer par définir un nouveau type de ressource:

ci / pipeline.yml

---
resource_types:
 - name: npm-cache
   type: docker-image
   source:
     repository: ymedlop/npm-cache-resource
     tag: latest

Pour séparer les processus en intégration continue des données transitant par le système, Concourse décharge toutes les informations d’état sur des abstractions appelées * ressources *. Les ressources sont des sources externes de données que Concourse peut utiliser pour extraire des informations ou pour y envoyer des informations. Voici comment toutes les données entrent dans le système d’intégration continue et comment toutes les données sont partagées entre les tâches. Concourse ne fournit aucun mécanisme pour stocker ou transmettre un état interne entre les travaux.

L’en-tête * resource_types * vous permet de définir de nouveaux types de ressources que vous pouvez utiliser dans votre pipeline, telles que les notifications par courrier électronique, les intégrations Twitter ou les flux RSS. Le nouveau type de ressource que nous définissons indique à Concourse comment utiliser npm-cache-resource, une ressource fournie sous la forme d’une image Docker qui permet à Concourse d’installer les dépendances de un projet Node.js et les partager entre les travaux.

Définir le référentiel et les ressources de mise en cache

Ensuite, nous devons définir les ressources réelles du pipeline:

ci / pipeline.yml

. . .

resources:
 - name: hello_hapi
   type: git
   source: &repo-source
     uri: https://github.com//hello_hapi
     branch: master
 - name: dependency-cache
   type: npm-cache
   source:
     <<: *repo-source
     paths:
       - package.json

Cette section définit deux ressources dont les travaux Concourse CI ont besoin pour effectuer leurs tâches. Concourse utilise les définitions de ressources pour surveiller les modifications apportées aux systèmes en amont et pour comprendre comment extraire la ressource lorsque les tâches le nécessitent. Par défaut, Concourse vérifie les nouvelles versions de chaque ressource une fois par minute. Les travaux nécessitant des ressources pour lesquelles l’option «déclencheur» est définie déclencheront automatiquement la création d’une nouvelle version lorsqu’une nouvelle version est disponible.

La première ressource représente votre fork du référentiel + hello_hapi + sur GitHub. La ligne «source» contient un YAML anchor appelé «repo-source» qui marque l’élément pour référence future. Cela nous permet d’inclure le contenu de l’élément (les définitions «uri» et «branch») à un emplacement différent plus tard dans le document.

La deuxième ressource, appelée «dependency-cache», utilise le type de ressource «npm-cache» que nous avons défini pour télécharger les dépendances du projet. Dans la spécification "source" de cette ressource, nous utilisons la ligne + <<: * repo-source pour référencer et extendo les éléments pointés par l’ancre` + & repo-source + . Cela insère les paramètres uri et branche de notre ressource de référentiel d’applications dans cette seconde ressource. Un élément supplémentaire appelé «chemins» pointe vers le fichier `+ package.json + où les dépendances du projet sont définies.

Définir les tâches de collecte et de test de dépendance

Enfin, nous définissons les processus d’intégration continue réels à l’aide de Concourse * jobs *:

ci / pipeline.yml

. . .

jobs:
 - name: Install dependencies
   plan:
     - get: hello_hapi
       trigger: true
     - get: dependency-cache
 - name: Run tests
   plan:
     - get: hello_hapi
       trigger: true
       passed: [Install dependencies]
     - get: dependency-cache
       passed: [Install dependencies]
     - task: run the test suite
       file: hello_hapi/ci/tasks/run_tests.yml

Dans cette section, nous définissons deux travaux, chacun consistant en un nom et un plan. Chacun de nos plans, à son tour, contient des éléments «get» et «task». Les éléments * task * spécifient comment exécuter une action tandis que les éléments * get * indiquent les dépendances de ressources de la tâche.

Le premier travail n’a aucune déclaration de tâche. C’est un peu inhabituel, mais cela a du sens quand on regarde ce qu’il fait et comment il peut être utilisé. La première instruction get nécessite la ressource + hello_hapi + et spécifie l’option + trigger: true +. Ceci indique à Concourse de récupérer automatiquement le référentiel et de commencer une nouvelle construction de ce travail chaque fois qu’une nouvelle validation est détectée dans le référentiel + hello_hapi +.

La deuxième instruction get du premier travail (+ get: dependency-cache +) requiert la ressource que nous avons définie, qui télécharge et met en cache les dépendances Node.js du projet. Cette instruction évalue les exigences présentes dans le fichier + package.json + et les télécharge. En l’absence de tâches définies pour ce travail, aucune autre action n’est entreprise, mais les dépendances téléchargées seront disponibles pour les travaux suivants.

Le second travail (+ nom: Exécuter les tests +) commence par déclarer les mêmes dépendances avec une différence notable. La contrainte «passée» fait que les instructions get ne correspondent qu’aux ressources qui ont franchi avec succès les étapes précédentes du pipeline. C’est ainsi que les dépendances entre les tâches sont formées pour enchaîner les processus de pipeline.

Après les instructions get, une tâche appelée «exécuter la suite de tests» est définie. Plutôt que de définir les étapes pour terminer en ligne, il demande à Concourse d’extraire la définition d’un fichier dans le référentiel qu’il a récupéré. Nous allons créer ce fichier ensuite.

Lorsque vous avez terminé, le pipeline complet devrait ressembler à ceci:

ci / pipeline.yml

---
resource_types:
 - name: npm-cache
   type: docker-image
   source:
     repository: ymedlop/npm-cache-resource
     tag: latest

resources:
 - name: hello_hapi
   type: git
   source: &repo-source
     uri: https://github.com//hello_hapi
     branch: master
 - name: dependency-cache
   type: npm-cache
   source:
     <<: *repo-source
     paths:
       - package.json

jobs:
 - name: Install dependencies
   plan:
     - get: hello_hapi
       trigger: true
     - get: dependency-cache
 - name: Run tests
   plan:
     - get: hello_hapi
       trigger: true
       passed: [Install dependencies]
     - get: dependency-cache
       passed: [Install dependencies]
     - task: run the test suite
       file: hello_hapi/ci/tasks/run_tests.yml

Enregistrez et fermez le fichier lorsque vous avez terminé.

Définir la tâche de test

Alors que la définition du pipeline décrivait la structure de notre processus d’intégration continue, elle différait la définition de la tâche de test réelle dans un autre fichier. L’extraction de tâches permet de garder la définition du pipeline concise et facile à lire, mais vous oblige à lire plusieurs fichiers pour comprendre l’ensemble du processus.

Ouvrez un nouveau fichier dans le répertoire + ci / tasks + appelé + run_tests.yml +:

nano ci/tasks/run_tests.yml

Pour définir une tâche, vous devez spécifier le type de système d’exploitation requis par le travailleur, définir l’image utilisée pour exécuter les tâches, nommer les entrées ou les sorties que la tâche utilisera et spécifier la commande à exécuter.

Collez le contenu suivant pour configurer notre tâche de test:

ci / tasks / run_tests.yml

---
platform: linux

image_resource:
 type: docker-image
 source:
   repository: node
   tag: latest

inputs:
 - name: hello_hapi
 - name: dependency-cache

run:
 path: hello_hapi/ci/scripts/run_tests.sh

Dans la configuration ci-dessus, nous spécifions que cette tâche nécessite un agent Linux. Le serveur Concourse lui-même peut satisfaire à cette exigence sans configuration supplémentaire.

Ensuite, nous indiquons une image qui sera utilisée par le travailleur pour exécuter la tâche. Bien que vous puissiez créer et utiliser vos propres types d’images, il s’agira presque toujours d’une image Docker. Étant donné que notre référentiel est une application Node.js, nous sélectionnons la dernière image de «nœud» pour exécuter nos tests car les outils appropriés ont déjà été installés.

Les tâches auxiliaires peuvent spécifier des entrées et des sorties pour indiquer les ressources auxquelles elle doit accéder et les artefacts qu’elles produiront. Les entrées correspondent aux ressources mobilisées plus tôt au niveau «travail». Le contenu de ces ressources est mis à la disposition de l’environnement de tâche sous la forme d’un répertoire de niveau supérieur pouvant être manipulé lors de l’exécution de la tâche. Ici, le référentiel d’application sera disponible dans le répertoire + hello_hapi + et les dépendances Node.js seront disponibles dans un répertoire appelé + dependency-cache +. Votre étape d’exécution peut avoir besoin de déplacer des fichiers ou des répertoires vers leur emplacement prévu au début des tâches et de placer des artefacts dans des emplacements de sortie à la fin des tâches.

Enfin, l’élément * run * répertorie le * chemin * de la commande à exécuter. Chaque tâche ne peut être qu’une seule commande avec des arguments. Par conséquent, s’il est possible de construire une commande en ligne en composant une chaîne bash, il est plus courant de pointer la tâche vers un fichier de script. Dans ce cas, nous pointons sur un script du répertoire d’entrée + hello_hapi + situé dans + hello_hapi / ci / scripts / run_tests.sh +. Nous allons créer ce script ensuite.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Définir le script de test

Enfin, nous devons créer le script que la tâche va exécuter. Ouvrez un nouveau fichier nommé + run_tests.sh + situé dans + ci / scripts / run_tests.sh +:

nano ci/scripts/run_tests.sh

Ce script manipulera les entrées de l’environnement de test pour déplacer les éléments vers leur emplacement correct. Il exécutera ensuite la suite de tests définie dans le référentiel en exécutant + npm test.

Collez les éléments suivants dans le nouveau fichier:

ci / scripts / run_tests.sh

#!/usr/bin/env bash

set -e -u -x

mv dependency-cache/node_modules hello_hapi
cd hello_hapi && npm test

Tout d’abord, nous indiquons que ce script doit être exécuté par l’interpréteur du conteneur Docker + bash. Les options + set + modifient le comportement par défaut du shell pour que des erreurs ou des variables non définies arrêtent l’exécution du script et impriment chaque commande à mesure de son exécution. Cela contribue à rendre le script plus sûr et donne une plus grande visibilité aux fins de débogage.

La première commande que nous exécutons déplace les dépendances mises en cache, situées dans le répertoire + node_modules +, du répertoire + dependency-cache + vers le répertoire + hello_hapi +. N’oubliez pas que ces deux répertoires sont disponibles car nous les avons spécifiés en tant qu’entrées dans la définition de la tâche. Ce nouvel emplacement est l’endroit où + npm + cherchera les dépendances téléchargées nécessaires.

Ensuite, nous passons dans le référentiel d’application et exécutons + npm test + pour exécuter la suite de tests définie.

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Avant de poursuivre, marquez le nouveau script comme exécutable afin qu’il puisse être exécuté directement:

chmod +x ci/scripts/run_tests.sh

Notre pipeline et tous les fichiers associés ont maintenant été définis.

Mise en place du pipeline dans le hall

Avant de fusionner la branche + pipeline + dans + main + et de la pousser jusqu’à GitHub, nous devrions aller de l’avant et charger notre pipeline dans Concourse. Concourse surveillera notre référentiel pour détecter les nouveaux commits et exécutera nos procédures d’intégration continue lorsque des modifications seront détectées.

Alors que nous devons charger le pipeline manuellement, Concourse lira les tâches et les scripts à partir des répertoires du référentiel lors de son exécution. Toute modification apportée au pipeline doit être rechargée dans Concourse pour prendre effet, mais comme nous n’avons pas tout défini en ligne, les modifications apportées aux tâches ou aux scripts sont automatiquement détectées lors de leur téléchargement dans le cadre d’une validation.

Pour configurer un nouveau pipeline, ciblez votre serveur Concourse avec la commande fly en utilisant l’action + set-pipeline +. Nous devons passer le nom du nouveau pipeline avec l’option + -p + et le fichier de configuration du pipeline avec l’option + -c +:

fly -t main set-pipeline -p hello_hapi -c ci/pipeline.yml

Vous serez invité à confirmer la configuration avant de continuer. Tapez * y * et appuyez sur * ENTER *:

Output. . .

apply configuration? [yN]:
pipeline created!
you can view your pipeline here: https://example.com/teams/main/pipelines/hello_hapi

the pipeline is currently paused. to unpause, either:
 - run the unpause-pipeline command
 - click play next to the pipeline in the web ui

Comme l’indique la sortie, le pipeline a été accepté mais est actuellement en pause. Vous pouvez rétablir le pipeline avec soit + fly + ou l’interface utilisateur Web. Nous allons utiliser l’interface utilisateur Web.

Dans votre navigateur Web, visitez votre serveur Concourse et connectez-vous. Vous devriez voir votre nouveau pipeline défini visuellement:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/inactive_pipeline.png [Pipeline inactif du cours]

Les tâches en attente sont représentées par des zones grises et les ressources sont des blocs plus petits et plus sombres. Les tâches déclenchées par des modifications de ressources sont reliées par des lignes continues, tandis que les ressources non déclencheuses utilisent des lignes interrompues. Le flux de ressources out des travaux indique qu’une contrainte + passée + a été définie pour le travail suivant.

L’en-tête bleu indique que le pipeline est actuellement en pause. Cliquez sur l’icône de menu * (trois lignes horizontales empilées) dans le coin supérieur gauche pour ouvrir le menu. Vous devriez voir une entrée pour votre pipeline (vous devrez peut-être vous déconnecter et vous reconnecter si le pipeline n’est pas visible). Cliquez sur l’icône bleue * play * à côté du pipeline pour annuler la pause:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/unpause_pipeline.png [Concourse suspendre le pipeline]

Le pipeline devrait maintenant être sans pause et commencer à fonctionner.

Au tout début, diverses ressources et tâches peuvent devenir orange, indiquant que des erreurs se sont produites. Cela est dû au fait que diverses images Docker doivent être téléchargées et que la branche + pipeline + doit encore être fusionnée dans la branche + main + de notre référentiel pour rendre les fichiers de tâche et de script disponibles.

Validation des modifications dans Git

Maintenant que le processus d’intégration continue est défini, nous pouvons l’enregistrer dans notre référentiel + git + et l’ajouter à Concourse.

Ajoutez le nouveau répertoire + ci + à la zone de stockage intermédiaire en tapant:

git add ci

Vérifiez les fichiers à valider en vérifiant l’état:

git status
OutputOn branch pipeline
Changes to be committed:
 (use "git reset HEAD <file>..." to unstage)

   new file:   ci/pipeline.yml
   new file:   ci/scripts/run_tests.sh
   new file:   ci/tasks/run_tests.yml

Validez les modifications en tapant:

git commit -m 'Add Concourse pipeline'

Les modifications sont maintenant appliquées à notre branche + pipeline +. Nous pouvons fusionner la branche dans la branche + master + en changeant de branche et en fusionnant:

git checkout master
git merge pipeline

Maintenant, poussez la branche + master + avec les nouvelles modifications vers GitHub:

git push origin master

Le commit lancera une nouvelle construction dans les soixante secondes et Concourse aura accès aux tâches et aux scripts du pipeline une fois les modifications apportées.

Voir la nouvelle construction

De retour dans l’interface utilisateur Web du Concourse, une nouvelle version commencera à progresser dans le pipeline au cours de la prochaine minute:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/running_test.png [Concourse exécutant la suite de tests]

Le contour jaune indique que le travail est en cours. Pour surveiller la progression, cliquez sur le travail * Exécuter les tests * pour afficher le résultat actuel. Une fois le travail terminé, la sortie complète sera disponible et le travail deviendra vert:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/successful_tests.png [Concours de tests réussis]

Cliquez sur l’icône * home * pour revenir à l’écran principal du pipeline. Le statut vert de chaque travail indique que la dernière validation a passé toutes les étapes du pipeline:

image: https: //assets.digitalocean.com/articles/concourse_usage_1604/passed_all_jobs.png [Le concours a passé tous les travaux]

Le pipeline continuera à surveiller le référentiel et exécutera automatiquement de nouveaux tests au fur et à mesure que les modifications sont validées.

Conclusion

Dans ce guide, nous avons configuré un pipeline Concourse pour surveiller automatiquement les modifications d’un référentiel. Lorsque les modifications sont détectées, Concourse extrait la dernière version du référentiel et utilise un conteneur Docker pour installer et mettre en cache les dépendances du projet. La construction passe ensuite à la phase de test où les dépendances sont copiées et la suite de tests du référentiel est exécutée pour vérifier si des modifications importantes ont été introduites.

Concourse offre beaucoup de flexibilité et de puissance pour définir des procédures de test isolées et les stocker dans le référentiel lui-même. Si vous souhaitez en savoir plus sur la manière d’utiliser Concourse pour vos propres projets, https://concourse.ci/introduction.html (consultez la documentation officielle)].

Related