Ci

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. ...

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 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. ...

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 : ...