Lab 08 — Déclencher un pipeline

Dans un projet réel, un pipeline ne doit pas dépendre uniquement d'un git push. Vous avez souvent besoin de lancer des tests chaque nuit, de déclencher un rebuild depuis un outil externe, ou de relancer un pipeline à la demande après une alerte monitoring. Ce lab vous montre comment faire avec les déclencheurs GitLab natifs.

Ce que vous allez apprendre

Déclencher un pipeline via un schedule GitLab
Déclencher un pipeline via API et trigger token
Comprendre les valeurs de $CI_PIPELINE_SOURCE
Écrire des rules spécifiques au type de déclenchement

Quel lab commencer ?

Ce lab vient après Lab 07. Si vous êtes déjà à l'aise avec la validation de pipeline, vous pouvez commencer directement depuis starter/lab-08.

Dans quel contexte ?

Les équipes DevOps utilisent plusieurs sources de déclenchement selon le besoin :

push et merge request pour la validation continue
schedule pour les tests de régression nocturnes
API/trigger pour orchestrer des pipelines depuis d'autres systèmes

Sans cette maîtrise, vous limitez l'automatisation et vous ratez des scénarios importants.

Prérequis

Lab 07 — Valider un pipeline terminé
Avoir lu Déclencheurs de pipelines

Point de départ

Basculez sur la branche du lab
Fenêtre de terminal
```
cd pipeline-craft
git checkout starter/lab-08
```
Ouvrez le .gitlab-ci.yml

Vous allez ajouter des règles basées sur la source du pipeline.

Le problème

Le pipeline gère déjà les runs MR, main et tags, mais il ne traite pas correctement les déclenchements schedule, trigger et api. Le but de ce lab est de rendre ces sources explicites dans workflow et dans les rules des jobs.

Vous allez faire évoluer le pipeline pour distinguer clairement :

push
schedule
trigger
api

L'exercice

Étape 1 — À vous d'ajouter des règles basées sur la source

Ajoutez un job dédié aux runs planifiés (schedule).
Remplacez les règles MR basées sur $CI_MERGE_REQUEST_IID par des règles basées sur la source du pipeline.
Ajoutez des règles explicites sur les jobs de validation pour distinguer :
- merge_request_event
- trigger
- api
Vérifiez que la logique dépend bien de CI_PIPELINE_SOURCE.

👉 Vérifier votre solution (Étape 1)

1️⃣ `workflow` basé sur `CI_PIPELINE_SOURCE`

Remplacez la règle MR historique par une règle source explicite et ajoutez les sources externes :

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_TAG
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_PIPELINE_SOURCE == "trigger"
    - if: $CI_PIPELINE_SOURCE == "api"

2️⃣ Job dédié aux runs planifiés

nightly-regression:
  stage: test
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - echo "Nightly run on source=$CI_PIPELINE_SOURCE"
    - pytest -v
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

3️⃣ Règles basées sur `$CI_PIPELINE_SOURCE`

Toutes les valeurs possibles :

Valeur	Déclencheur
`push`	`git push`
`merge_request_event`	Ouverture / mise à jour MR
`schedule`	Tâche planifiée GitLab
`trigger`	Trigger token
`api`	API REST GitLab
`web`	Bouton « Run pipeline » dans l'UI

Exemple sur un job existant (ruff-lint/pytest) :

ruff-lint:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "api"
    - if: $CI_PIPELINE_SOURCE == "trigger"

Étape 2 — À vous de créer un schedule dans GitLab

Allez dans Build > Pipeline schedules
Créez un schedule quotidien
Choisissez la branche cible et l'horaire GitLab évalue le cron en UTC. Si vous programmez 02:00 locale, vérifiez le décalage horaire pour éviter les surprises.

👉 Vérifier votre solution (Étape 2)

1️⃣ Créer un schedule dans GitLab

Allez dans Build > Pipeline schedules
Cliquez New schedule
Remplissez les champs :

Champ	Valeur exemple
Description	Régression nocturne
Interval Pattern	`0 2 * * *` (chaque nuit à 02:00 UTC)
Target branch	`main`
Active	✅

Cliquez Save pipeline schedule

Pour déclencher immédiatement en test, cliquez le bouton ▶ à droite du schedule dans la liste.

GitLab évalue le cron en UTC. 0 2 * * * = 02:00 UTC = 03:00 Paris (heure d'été) ou 03:00 (heure d'hiver).

Étape 3 — À vous de déclencher via API avec trigger token

Générez un token dans Settings > CI/CD > Pipeline trigger tokens.
Déclenchez un pipeline via l'API GitLab avec ce token.
Vérifiez dans GitLab que la source du pipeline est trigger.

Vous devez appeler l'endpoint de trigger du projet avec le token et une référence de branche.

👉 Vérifier votre solution (Étape 3)

1️⃣ Générer un trigger token

Allez dans Settings > CI/CD > Pipeline trigger tokens
Saisissez une description : test external trigger
Cliquez Add trigger token et copiez le token généré

2️⃣ Appeler l'API pour déclencher un pipeline

curl -X POST \
  --fail \
  -F token=<YOUR_TRIGGER_TOKEN> \
  -F ref=main \
  "https://gitlab.com/api/v4/projects/<PROJECT_ID>/trigger/pipeline"

Récupérez <PROJECT_ID> dans Settings > General > Project ID.

La réponse JSON confirme le déclenchement :

{
  "id": 12345,
  "status": "created",
  "source": "trigger"
}

Étape 4 — À vous de vérifier la source dans les logs

Ajoutez temporairement une ligne de debug qui affiche la valeur de CI_PIPELINE_SOURCE.
Lancez un pipeline de chaque type et comparez les valeurs observées.

Cette étape vous aide à valider vos règles sans ambiguïté.

👉 Vérifier votre solution (Étape 4)

1️⃣ Vérification dans les logs `pytest`

pytest:
  script:
    - echo "Pipeline source: $CI_PIPELINE_SOURCE"
    - pytest -v --junitxml=report.xml

Les logs affichent la valeur exacte selon le déclencheur :

MR → Pipeline source: merge_request_event
schedule → Pipeline source: schedule
trigger API → Pipeline source: trigger
API REST → Pipeline source: api

Vous pouvez garder cette ligne echo le temps du lab pour observer le routage des règles, puis la retirer ensuite.

Le fichier complet

📄 Voir le fichier .gitlab-ci.yml complet

stages:
  - lint
  - test
  - build
  - deploy

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_TAG
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_PIPELINE_SOURCE == "trigger"
    - if: $CI_PIPELINE_SOURCE == "api"

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"

ruff-lint:
  stage: lint
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
    policy: pull
  before_script:
    - pip install ruff
  script:
    - ruff check app/ tests/
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "api"
    - if: $CI_PIPELINE_SOURCE == "trigger"

pytest:
  stage: test
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - echo "Pipeline source: $CI_PIPELINE_SOURCE"
    - pytest -v --junitxml=report.xml
  artifacts:
    when: always
    paths:
      - report.xml
    reports:
      junit: report.xml
    expire_in: 7 days
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "api"
    - if: $CI_PIPELINE_SOURCE == "trigger"

nightly-regression:
  stage: test
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - echo "Nightly run on source=$CI_PIPELINE_SOURCE"
    - pytest -v
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

docker-build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-staging:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to staging..."
    - ./scripts/deploy-demo.sh staging
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to production..."
    - ./scripts/deploy-demo.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

Vérification

Un schedule déclenche bien un pipeline
Un trigger API déclenche bien un pipeline
Les jobs s'exécutent selon la valeur de CI_PIPELINE_SOURCE
Vous savez expliquer la différence entre trigger token et personal access token

Pièges fréquents

Le trigger token sert à déclencher un pipeline, pas à accéder à toute l'API GitLab. Le personal access token a un autre usage. Mélanger les deux est une erreur classique.

Autre point : un cron mal calé en UTC donne l'impression que le schedule ne fonctionne pas. Vérifiez toujours le fuseau horaire avant de conclure.

À retenir

Un pipeline GitLab peut être déclenché sans push
$CI_PIPELINE_SOURCE permet d'adapter les jobs au contexte
Schedule et API couvrent des besoins complémentaires
Tester vos règles par source évite les surprises en production

Prochaines étapes

Lab 09 — Publier dans le registry Pousser vos images et packages vers GitLab Registry

Guide : déclencheurs Référence complète des sources de pipeline

Retour au Lab 07 Validation avant push