Github-2 Création de pipelines 👩🏽💻
Objectifs:
🎯 Créer des pipelines déclenchés par différents évènements github.
Prérequis:
💡 [ Avoir un compte github ].
💡 [ Visual Studio Code installé ].
💡 [ Git installé ].
Bonjour, cette rubrique fait suite à la présentation de l'outil [ Github-Actions-1 Présentation de l'outil ] que je vous
conseille de visiter si vous n'avez pas de connaissances sur github actions.
1) Création d'un pipeline qui check la syntax de notre script shell sur les push de code.
1.1) Créer une nouvelle branche et créer le fichier .github/workflows/push-lint.yml.
1.2) Visiter le [ Github Actions Marketplace ] pour savoir quelle action utiliser et comment l'implémenter dans vos pipelines puis rechercher 'shell'.
1.3) Éditer le workflow push-lint.yml .
* Le workflow commence par la définition de son nom, notre pipeline s'appelle 'push-lint'.
* Ensuite on définit l'élément déclencheur du pipeline, ici on cible les push de code.
* Puis arrive le mot clés jobs qui va regrouper nos jobs et leur étapes.
* Définition du job 'lint-check'.
* Notre job 'lint-check' possède 2 étapes qui sont:
- le checkout du code sur le runner qui exécute le job.
- l'utilisateur de la version v0.6.0 du linter shell par azohra.
1.4) Pousser les modifications dans le repo github.
1.5) Vérifier la liste de nos pipelines présents dans la rubrique actions de notre repo.
1.6) Vérifier le status et les logs du pipeline.
1.7) Merger la branche dans la branche de référence (main).
2) Création d'un pipeline à déclencher manuellement qui crée un tag avec une sémentique de pré-release
2.1) Créer une nouvelle branche et créer le fichier prerelease_pipeline.yml dans le dossier .github/workflows/.
(1) nom du pipeline.
(2) déclenchement manuel avec un input component-version à renseigner.
(3) création d'une variable d'environnement à partir de l'input renseigné au déclenchement.
(4) output du step spécifié mis à l'échelle du job.
(5) checkout du repo à l'aide d'une action du marketplace de [ Github Actions ]
(6) pour utiliser hors du step un de ses output, le step doit obligatoirement avoir un id.
(7) envoie de la var tag-version dans les oputput du step 'set-tagversion'.
(8) Utilisation de jq pour retrouver la version de l'app à partir du json contenant les metadonnées du projet.
(9) mise en place de la notification 'project-version' dans le résumé du job.
2.2) Pousser le code, lancer le pipeline puis analyser les logs.
* Dans le résumé de l'éxécution du pipeline nous retrouvons les outputs manipulés dans le yml précédent.
* Essayez de faire le lien entre le Raw refname affiché avec le Raw refname déclaré en var d'env dans le yml.
* Je n'ai montré qu'un extrait de mon pipeline
* Dans la suite de mon pipeline:
- j'incrémente la version déclarée dans le project.json.
- je commit et push ce changement sur project.json.
- je taggue la branche avec le nouveau numéro de version.
* Je vous invite à essayer de finir un pipeline type.
Conclusion:
Nous venons de voir deux brefs exemples qui permettent d'avoir les bases sur les pipelines, il faudra cependant pratiquer pour bien s'imprégner de la syntaxe et se faire son mémento d'actions.
Il me semble important d'avoir sous la main les [ vars d'environnement github ],
encore une fois le [ Github Actions Marketplace ] et bien comprendre le partage de fichier et d'outputs entre les jobs.
Actuellement nos pipelines s'éxécutent en mode SAAS sur des machines github (ubuntu, macos, windows).
Dans le cas où vous voudriez les exécuter sur vos propres machines, rendez-vous au chapitre suivants [ Github-Actions-3: Self-hosted runners ]