Visualiseur GitLab CI

Comment ça marche

1. 01

   Collez ou déposez .gitlab-ci.yml

   Le fichier de pipeline à la racine de votre projet. Les ancres YAML, les modèles extends et les balises !reference sont acceptés, et un en-tête spec de composant CI/CD en tête de fichier est ignoré.

2. 02

   Voyez le pipeline en colonnes

   Les stages deviennent des colonnes de gauche à droite, chaque job se place dans la colonne de son stage, et needs relie les jobs qui démarrent avant leur stage.

3. 03

   Ouvrez-le dans Archboard

   Enregistrez-le comme nouveau diagramme pour réorganiser les jobs, ajouter des notes, partager un lien ou l’exporter en SVG et PNG. Un compte Google ou GitHub suffit pour s’inscrire.

Ce qui est dessiné à partir de .gitlab-ci.yml

Le diagramme suit ces mots-clés de votre fichier de pipeline :

• stagesstage

  Les stages en colonnes, dans l’ordre de votre liste stages, ou build, test et deploy en l’absence de liste. Un job sans stage va dans test, et les stages sans job ne sont pas dessinés.

• script

  Chaque job sous forme de carte dans la colonne de son stage. Les clés qui commencent par un point sont des modèles : elles ne sont pas dessinées comme jobs, mais elles façonnent toujours les jobs qui en héritent.

• needsneeds: []

  Un lien depuis chaque job listé sous needs, pour repérer les jobs qui démarrent avant leur stage. needs: [] marque un job qui démarre immédiatement. Un lien est en pointillés quand l’entrée needs est optionnelle ou que le job en attente a rules, only ou except.

• extends

  extends résolu sur jusqu’à 11 niveaux de modèles, avec les ancres YAML et les clés de fusion, pour que les valeurs héritées de stage, needs, when, parallel, trigger et environment soient dessinées.

• parallelparallel:matrix

  parallel: 3 ou parallel:matrix garde le job sous forme d’une seule carte, marquée ×3 ou du nombre de combinaisons de la matrice.

• trigger

  Les jobs de déclenchement reliés à une carte pour ce qu’ils lancent : le fichier de pipeline enfant indiqué dans trigger: include, ou le projet en aval dans trigger: project.

• environment

  Chaque environnement, comme review, staging ou production, sous forme de carte reliée aux jobs qui y déploient.

• when: manual

  Les jobs manuels marqués · manual, pour que les étapes de validation de votre pipeline ressortent.

Ce qu’un diagramme GitLab CI laisse de côté

• La configuration ajoutée avec include, qu’il s’agisse de fichiers locaux, d’autres projets, d’URL distantes, de modèles ou de composants CI/CD : elle n’est pas récupérée, et les jobs qui héritent d’un modèle de ces fichiers sont listés dans les avertissements.
• Si rules, only ou except ajouteraient ou ignoreraient un job : ils ne sont pas évalués, donc chaque job est dessiné.
• Les variables et leurs valeurs, les scripts, les images, les caches et les chemins d’artefacts.
• Les exécutions de pipeline : statut des jobs, durées, logs et artefacts. Le diagramme montre la configuration, pas une exécution précise.