Ci on FtBx.fr

GitLab CI parallel:matrix : les needs individuels sont enfin là

Wed, 03 Sep 2025 00:00:00 +0000

Avant, parallel:matrix permettait de lancer la même tâche sur plusieurs versions. Mais impossible de référencer UN job spécifique de la matrice dans un needs. Toute la matrice formait un bloc indivisible.

GitLab 16.7 a changé ça. Maintenant, tu peux needs un job précis de la matrice. Et ça débloque des pipelines plus propres.

Avant : le workaround

# ❌ Avant GitLab 16.7 : impossible de référencer un job de la matrice
test:
 parallel:
 matrix:
 - PYTHON: ["3.9", "3.10", "3.11"]
 script: pytest

deploy:
 needs: ["test"] # Attend TOUS les jobs de la matrice
 script: ./deploy.sh

Après : des needs chirurgicaux

# ✅ GitLab 16.7+ : on cible un job précis
test:
 parallel:
 matrix:
 - PYTHON: ["3.9", "3.10", "3.11"]
 script: pytest

deploy_39:
 needs: ["test: [3.9]"]
 script: ./deploy-py39.sh

deploy_latest:
 needs: ["test: [3.11]"]
 script: ./deploy-pylatest.sh

Le job deploy_39 attend UNIQUEMENT test: [3.9]. Il n’attend pas les tests Python 3.10 et 3.11. Résultat : le déploiement peut partir dès que sa version est validée, sans attendre les autres.

GitLab CI resource_group : empêcher deux déploiements concurrents

Wed, 15 Jan 2025 00:00:00 +0000

Quand deux pipelines déploient sur le même environnement en parallèle, le deuxième écrase le premier. Résultat : état incohérent, erreurs de connexion, rollback en catastrophe.

resource_group règle ça proprement. Tu assignes un nom de groupe à un job de déploiement. GitLab garantit qu’un seul job par groupe s’exécute à la fois. Les autres attendent.

deploy_staging:
 stage: deploy
 script: ./deploy.sh staging
 environment:
 name: staging
 resource_group: staging

Si deux pipelines arrivent en même temps sur deploy_staging, le premier s’exécute, le deuxième attend que le premier finisse. Pas de lock manuel, pas de vérification Slack “qui déploie ?”.

GitLab CI coverage regex : pourquoi ta regex ne matche jamais

Mon, 08 Apr 2024 00:00:00 +0000

GitLab peut extraire le pourcentage de couverture de tests depuis les logs du job et l’afficher dans le badge du projet, les MR, et l’UI. Il suffit de définir une regex dans coverage:. Et c’est là que tout le monde se plante.

La regex qui foire systématiquement

# ❌ Ne matchera JAMAIS
job:
 script: pytest --cov
 coverage: '/TOTAL.*\s+(\d+%)$/'

Pourquoi ? $ veut dire “fin de ligne”. Mais les logs GitLab sont collectés dans un buffer multi-lignes. La vraie fin de ligne dans ce buffer, c’est la dernière ligne du log entier, pas la ligne TOTAL.

gitlab-ci-local : tester ses pipelines sans pousser

Fri, 08 Mar 2024 00:00:00 +0000

Pousser un commit juste pour tester un changement de .gitlab-ci.yml, c’est 30 secondes par tentative. Sur une pipeline un peu tordue, 20 essais. 10 minutes perdues à corriger des erreurs de syntaxe.

gitlab-ci-local exécute tes pipelines en local, avec Docker. Tu modifies ton .gitlab-ci.yml, tu lances gitlab-ci-local, tu vois les erreurs immédiatement. Zéro push, zéro attente de runner.

# Installer
npm install -g gitlab-ci-local

# Lancer tous les jobs du .gitlab-ci.yml courant
gitlab-ci-local

# Lancer un job spécifique
gitlab-ci-local --job build

# Lister les jobs disponibles
gitlab-ci-local --list

Ce que ça supporte

image, services, before_script, script, after_script
artifacts, cache (local, pas partagé)
variables, extends, !reference, needs
parallel:matrix (partiellement)

Ce que ça NE supporte PAS

trigger (pipelines enfants)
environment (pas de déploiement réel)
rules:if avec des variables GitLab prédéfinies ($CI_COMMIT_BRANCH)
Runner tags, Kubernetes executor

Le piège

gitlab-ci-local utilise Docker pour exécuter les jobs. Si ton job fait référence à $CI_REGISTRY_IMAGE ou $CI_JOB_TOKEN, ces variables n’existent pas en local. Il faut les définir manuellement :