DAG et parallélisme GitLab CI/CD (needs)

Vos pipelines attendent la fin d’un stage complet alors qu’un seul job est nécessaire ? Avec needs: (DAG), un job démarre dès que ses vraies dépendances sont terminées, sans attendre tout le stage. Résultat : des pipelines souvent sensiblement plus rapides (et surtout plus parallèles).

En 30 secondes

# Sans needs : deploy attend la fin de TOUT le stage test
# Avec needs : deploy démarre dès que unit_tests finit

deploy:
  stage: deploy
  needs: ["unit_tests"]  # N'attend pas lint, ni integration_tests
  script: ./deploy.sh

Ce guide est fait pour vous si…

Pipeline trop long Les jobs attendent inutilement.

Dépendances complexes Un job dépend d'un seul autre, pas de tout un stage.

Visualiser le graphe Voir les vraies dépendances dans GitLab.

Éviter les erreurs Dépendances circulaires et autres pièges.

Prérequis

Avant de continuer, assurez-vous de maîtriser :

• Concepts fondamentaux GitLab CI/CD
• Artefacts et cache

Le problème sans DAG

Par défaut, GitLab exécute les pipelines stage par stage :

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script: npm run build

lint:
  stage: test
  script: npm run lint

unit_tests:
  stage: test
  script: npm test

integration_tests:
  stage: test
  script: npm run test:integration

deploy:
  stage: deploy
  script: ./deploy.sh

Problème : deploy attend que lint, unit_tests ET integration_tests soient tous terminés, même si deploy n’a besoin que de build.

Configuration avec needs

needs: définit les vraies dépendances d’un job :

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script: npm run build
  artifacts:
    paths:
      - dist/

lint:
  stage: test
  script: npm run lint
  needs: []                    # Pas de dépendance, démarre immédiatement

unit_tests:
  stage: test
  script: npm test
  needs: ["build"]             # Attend seulement build

integration_tests:
  stage: test
  script: npm run test:integration
  needs: ["build"]

deploy:
  stage: deploy
  script: ./deploy.sh
  needs: ["unit_tests"]        # N'attend pas lint ni integration_tests

Résultat :

Le pipeline est plus rapide car deploy n’attend pas lint ni integration_tests.

Options de needs

Liste simple

deploy:
  needs: ["build", "test"]

Avec artefacts

Par défaut, needs télécharge les artefacts des jobs référencés. Pour désactiver :

deploy:
  needs:
    - job: build
      artifacts: true      # Télécharge les artefacts (défaut)
    - job: lint
      artifacts: false     # N'a pas besoin des artefacts de lint

Piège : téléchargement d'artefacts

Dès qu’un job utilise needs, GitLab n’applique plus le comportement par défaut “télécharger les artefacts des stages précédents”. Vous ne récupérez que les artefacts des jobs listés dans needs (contrôlés via artifacts: true/false).

needs: [] — aucune dépendance

Un job avec needs: [] démarre immédiatement, sans attendre la fin du stage précédent :

lint:
  stage: test
  needs: []          # Démarre en même temps que build !
  script: npm run lint

Astuce performance

needs: [] est parfait pour les jobs qui n’ont pas besoin des artefacts de build : lint, analyse statique, vérification de formatage. Ils démarrent dès la création du pipeline.

needs avec optional

Si un job peut ne pas exister (conditionné par rules), optional: true évite que le pipeline échoue à la création :

deploy:
  needs:
    - job: build
    - job: security_scan
      optional: true     # Le job peut ne pas exister (rules non matchées)

Limites et cas particuliers

Limite / Cas	Détail
Max 50 jobs	Par défaut, needs accepte max 50 jobs (ajustable en self-managed)
Parallel	Si needs référence un job avec parallel:, il dépend de tous les jobs parallélisés
Même stage	needs peut référencer des jobs du même stage
Ne pas mélanger	Évitez de combiner needs et dependencies dans un même job

Glissez pour voir

needs:project (avancé)

needs:project permet de télécharger des artefacts depuis d’autres pipelines/projets. Utile pour les bibliothèques partagées, mais avec des contraintes (même instance, permissions).

Visualiser le DAG

GitLab affiche le graphe de dépendances dans l’interface :

1. Allez dans Build > Pipelines

2. Cliquez sur un pipeline

3. Sélectionnez l’onglet Needs (ou regardez le graphe qui montre les flèches)

Le graphe montre les vraies dépendances entre jobs, pas l’organisation par stages.

Exemples pratiques

Pipeline Node.js optimisé

stages:
  - prepare
  - quality
  - build
  - test
  - deploy

install:
  stage: prepare
  script: npm ci
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - node_modules/
  artifacts:
    paths:
      - node_modules/
    expire_in: 1 hour

# Jobs de qualité : pas de dépendance, démarrent immédiatement
lint:
  stage: quality
  needs: []
  script: npm run lint

format_check:
  stage: quality
  needs: []
  script: npm run format:check

# Build : attend seulement install
build:
  stage: build
  needs: ["install"]
  script: npm run build
  artifacts:
    paths:
      - dist/

# Tests : en parallèle, chacun attend seulement ce dont il a besoin
unit_tests:
  stage: test
  needs: ["install"]
  script: npm test

e2e_tests:
  stage: test
  needs: ["build"]           # A besoin du build
  script: npm run test:e2e

# Deploy : attend les tests critiques, pas le lint
deploy_staging:
  stage: deploy
  needs: ["unit_tests", "build"]
  script: ./deploy.sh staging

Monorepo avec services indépendants

stages:
  - build
  - test
  - deploy

# Frontend et Backend buildent en parallèle
build_frontend:
  stage: build
  script: npm run build:frontend
  artifacts:
    paths:
      - frontend/dist/

build_backend:
  stage: build
  script: npm run build:backend
  artifacts:
    paths:
      - backend/target/

# Tests indépendants
test_frontend:
  stage: test
  needs: ["build_frontend"]
  script: npm run test:frontend

test_backend:
  stage: test
  needs: ["build_backend"]
  script: npm run test:backend

# Déploiements indépendants
deploy_frontend:
  stage: deploy
  needs: ["test_frontend"]
  script: ./deploy-frontend.sh

deploy_backend:
  stage: deploy
  needs: ["test_backend"]
  script: ./deploy-backend.sh

Le frontend et le backend sont complètement indépendants. Si le backend est lent, le frontend se déploie quand même.

Bonnes pratiques

1. Minimisez les dépendances : un job ne doit dépendre que de ce qui est strictement nécessaire.

2. Utilisez needs: [] pour les jobs sans dépendances réelles (lint, format, analyse statique).

3. Séparez les artefacts : ne passez que ce qui est nécessaire avec artifacts: false.

4. Visualisez le graphe : utilisez l’interface GitLab pour valider vos dépendances.

5. Gardez les stages : les stages restent utiles pour l’organisation visuelle, même avec DAG.

Erreurs fréquentes

Erreur	Cause	Solution
circular dependency	Job A needs B, Job B needs A	Revoir l’architecture
too many dependencies	Plus de 50 jobs dans needs	Réduire ou ajuster la limite (self-managed)
Job attend trop longtemps	Dépendance inutile dans needs	Supprimer les dépendances non nécessaires
Artefacts non trouvés	Job dans needs n’a pas d’artefacts	Vérifier artifacts: dans le job source
Artefacts manquants (stage précédent)	needs désactive le téléchargement auto	Ajouter explicitement le job dans needs
needs: [] mais job échoue	Le job a besoin d’artefacts	Ajouter la vraie dépendance

Glissez pour voir

Dépendances circulaires

Un DAG est acyclique — pas de boucles. Ceci est interdit :

job_a:
  needs: ["job_b"]

job_b:
  needs: ["job_a"]  # ❌ Boucle !

À retenir

1. needs définit les vraies dépendances, pas les stages
2. needs: [] = aucune dépendance, démarre immédiatement
3. Artefacts : avec needs, seuls ceux des jobs listés sont téléchargés
4. Limite : max 50 jobs dans needs par défaut
5. Pas de boucles — les dépendances doivent être acycliques
6. Ne pas mélanger needs et dependencies dans un même job
7. Visualisez le graphe dans GitLab pour valider

Prochaines étapes

Pipelines parent-enfant Orchestrer les monorepos avec trigger.

Artefacts et cache Optimiser le partage de fichiers.

×

📖 Voir la documentation →