Valider des pipelines Gitlab CI/CD

Je pense que comme moi vous vous agacez du nombre d’erreurs, parfois bête, que vous rencontrez lorsqu’on soumet son fichier .gitlab-ci.yml.

Après quelques recherches voici quelques solutions pour le valider avant de le pousser dans le repository. Pour ceux qui ne connaissent pas aux fonctionnalités CI-CD de gitlab, je vous renvoie à ce billet.

Comment valider son pipeline avant de le soumettre ?

L’outil Lint présent dans l’interface de Gitlab

Gitlab possède un outil permettant de valider la syntaxe de son fichier .gitlab-ci.yml. Il se trouve dans le menu CI/CD > Pipelines et réponds au nom de CI Lint.

Il suffit de copier/coller son fichier .gitlab-ci.yml et de cliquer sur le bouton [Validate].

Dans la partie basse de l’interface, on retrouve le rapport qui indique soit :

• Syntaxe is incorrect Avec la ou les erreurs rencontrée(s), ex jobs deploy web config should implement a script: or a trigger: keyword
• Syntax is correct.

Il est possible de demander une simulation du CI avec la case à cocher [Simulate]. Les simulations s’exécutent comme un git push sur la branche par défaut. Vous devez donc avoir les autorisations pour créer des pipelines sur cette branche pour lancer une validation avec simulation.

L’outil editor présent dans le menu CI/CD

Cet outil est en fait un éditeur en ligne de fichier .gitlab-ci.yml. Il utilise l’outil précédent pour valider à chaque frappe que le fichier est correct et propose bien sûr de l’autocomplétion en partie.

Une des options sympathiques est de pouvoir visualiser le pipeline. Bien utile lorsqu’on ajoute des dépendances utilisant les Directed Acyclic Graphs: l’option needs.

Via l’API gitlab

Gitlab propose une API permettant de réaliser pas mal d’action, dont la validation du fichier .gitlab-ci.yml.

Avant de le soumettre il faut créer un PAT avec les droits api + read_user. Pour cela il faut de se rendre dans vos users settings > Access Tokens et de créer votre token comme ci-dessous.

Ensuite via une commande curl :

curl --header "Content-Type: application/json" --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/ci/lint" --data '{"content": "{ \"image\": \"ruby:2.6\", \"services\": [\"postgres\"], \"before_script\": [\"bundle install\", \"bundle exec rake db:create\"], \"variables\": {\"DB_NAME\": \"postgres\"}, \"types\": [\"test\", \"deploy\", \"notify\"], \"rspec\": { \"script\": \"rake spec\", \"tags\": [\"ruby\", \"postgres\"], \"only\": [\"branches\"]}}"}'

Ça fonctionne, mais ce n’est pas des plus conviviales. Plus d’infos ici ↗

L’extension Officielle Gitlab Workflow de vscode

Pour ceux qui comme moi utilise VsCode comme éditeur, il est possible de valider son CI directement. Cette extension utilise en fait l’API de Gitlab pour soumettre le fichier .gitlab-ci.yml.

Il faut ci-dessus créer un PAT avec les droits api + read_user. Pour cela il faut de se rendre dans vos users settings > Access Tokens et de créer votre token comme ci-dessous.

Ensuite dans vscode tapez [CTRL] + [Shift] + [P] et rechercher gitlab: Set .... Entrez l’url de votre serveur gitlab si vous hébergez votre propre serveur Gitlab et en ensuite le token généré précédemment. En cas d’erreur il faut utiliser [CTRL] + [Shift] + [P] et rechercher gitlab: Remove ...

Désormais vous pouvez valider votre CI en tapant [CTRL] + [Shift] + [P] et rechercher gitlab: Validate Gitlab.... Vous pouvez configurer votre propre combinaison de touche pour accélérer le traitement.

On peut également en cliquant sur l’icône gitlab (image ci-dessus) voir les Issues, MR et les pipelines du projet. En cliquant sur les différents items visualcode renvoie sur la page concernée dans votre navigateur.

Lancer des jobs de CI localement

Allons plus loin en lançant les jobs et cela localement. Pour éviter les erreurs, faites cela sur une copie de votre projet. Il existe deux possibilités pour arriver à ce résultat.

En installant un gitlab runner

Téléchargez le binaire de gitlab runner correspondant à votre machine de dev depuis cette url ↗ et installez le.

Ensuite ajouter le user gitlab-runner au groupe docker. Enregister un runner sur votre projet ou groupe dans l’option Settings > CI/CD > Runners

À partir de maintenant il est possible de lancer localement des jobs de votre CI.

gitlab-runner exec docker "deploy web"
Running with gitlab-runner 14.3.2 (e0218c92)
Preparing the "docker" executor
Using Docker executor with image python:3-alpine3.14 ...
Pulling docker image python:3-alpine3.14 ...
Using docker image sha256:c9e1987b6bc66ca93a8d6ecd5f0500082a364aec1563b754f40eaf1084f3e2ad for python:3-alpine3.14 with digest python@sha256:c13a6cf74fb452f9eab9f1a521f3ff6d056d5bc51b1a29bfe4758fcb00135394 ...
Preparing environment
Running on runner--project-0-concurrent-0 via devbox...
Getting source from Git repository
...

Si vous avez besoin d’injecter des variables il faut ajouter l’option —env:

gitlab-runner exec docker --env CI_COMMIT_REF_SLUG="master" --env CI_PROJECT_NAME="aws-blog" "deploy web"

C’est bien utile, mais on ne peut enchaîner des jobs directement. Voyons un autre outil.

En utilisant l’outil python gitlabci-local

En cherchant un peu je suis tombé sur ce projet ↗ et j’ai été rapidement séduit.

Pour l’installer rien de plus simple avec pip ou pipx car je vous conseille de l’installer dans un environnement virtuel.

pyenv install 3.9.7
pyenv virtualenv 3.9.7 gitlabci-local
pyenv local gitlabci-local
pip install pipenv
pipenv install --dev gitlabci-local

Voici les principales commandes :

• gitlabci-local: Lance le menu interactif permettant de choisir un ou plusieurs jobs à lancer.
• gitlabci-local -p: Lance le pipeline automatiquement
• gitlabci-local ‘Dev’: Lance des jobs dont le nom contient une chaîne donnée
• gitlabci-local ‘Job 1’: —debug: Le container de travail est conservé et pour se connecter il suffit de taper la commande docker exec ... affiché en fin de traitement.
• gitlabci-local ‘Job 1’ —bash: Idem à ci-dessus, mais lance simplement un shell
• gcil: Alias de raccourci vers gitlabci-local

gitlabci-local

 ===[ Jobs selector ]=== [deploy web]


 ===[ deploy: deploy web (python:3-alpine3.14, docker) ]===

+ apk --no-cache add hugo curl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz

Pour lancer localement les CI sans utiliser les images indiquées dans les steps, il faut simplement ajouter l’option -H ou --host. Cela permet de lancer le pipeline en utilisant les outils installées sur votre machine. Une sorte de Make ou Taskfile.

Vraiment sympa tous ces outils ! Faites en bon usage.