Générateur pipeline GitLab CI (.gitlab-ci.yml)

GitLab CI : principes

GitLab CI/CD est le système d'intégration et de déploiement continu intégré à GitLab. Il se configure via un fichier .gitlab-ci.yml à la racine du dépôt.

Structure du .gitlab-ci.yml

# Définir les stages dans l'ordre d'exécution
stages:
  - install
  - test
  - build
  - deploy

# Image Docker par défaut pour tous les jobs
default:
  image: node:20-alpine

# Variables globales
variables:
  NODE_ENV: "production"

# Template réutilisable
.base-rules: &base-rules
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Stages et jobs

install:dependencies:
  stage: install
  script:
    - npm ci
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
    policy: push

test:unit:
  stage: test
  script:
    - npm test
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
    policy: pull  # ne met pas à jour le cache

build:app:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour

Cache et artifacts

Variables CI/CD

Définissez vos secrets dans Settings → CI/CD → Variables. GitLab masque automatiquement les variables marquées "Masked" dans les logs.

Bonnes pratiques

• ✅ Utiliser des templates YAML (& et *) pour éviter la duplication
• ✅ Séparer les policies du cache : push dans le job d'install, pull ailleurs
• ✅ Utiliser rules: à la place de only:/except: (déprécié)
• ✅ Épingler les versions des images Docker : node:20-alpine, pas node:latest
• ✅ Activer le déploiement manuel en production avec when: manual
• ✅ Définir des environnements (environment: name: production) pour le suivi des déploiements
• ✅ Utiliser interruptible: true sur les jobs CI pour libérer les runners lors d'un force push