gitlab-ci-guidelisted

# Guide GitLab CI/CD ## 1. Concevoir la structure du pipeline Définir les stages dans l'ordre d'exécution logique. Les jobs d'un même stage tournent en parallèle ; `needs:` casse cette contrainte pour du DAG. ```yaml stages: - build - test - analyze - deploy ``` **Critères de découpage :** - Un stage = une responsabilité (ne pas mélanger build et test). - Si un job doit démarrer avant la fin de son stage, utiliser `needs:` (DAG). - Limiter à 6-7 stages max, au-delà, refactorer en pipelines enfants. ## 2. Écrire les jobs Structure minimale d'un job de référence : ```yaml build:app: stage: build image: node:22-alpine before_script: - npm ci --cache .npm --prefer-offline script: - npm run build artifacts: paths: - dist/ expire_in: 1 day cache: key: files: - package-lock.json paths: - .npm/ ``` **Règles d'exécution, préférer `rules:` à `only/except`** : ```yaml deploy:production: stage: deploy rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH when: manual - if: $CI_PIPELINE_SOURCE == "merge_request_event" when: never environment: name: production url: https://app.example.com ``` ## 3. Gérer les runners | Type | Cas d'usage | Config clé | |------|------------|------------| | Shared runners | CI standard, projets publics | Tags vides ou `saas-linux-*` | | Group runners | Équipe partageant des secrets d'infra | `group_runners_enabled: true` | | Project runners | Accè