Lab 11 — Débugger un job bloqué

Quand un job est rouge, vous avez des logs. Quand un job reste en pending ou qu’un pipeline apparaît skipped, c’est plus déroutant : parfois il n’y a presque aucun indice visible. Ce lab vous donne une méthode de diagnostic fiable pour ces deux cas fréquents.

Ce que vous allez apprendre

Diagnostiquer un job bloqué en pending
Diagnostiquer un pipeline skipped
Lire les indices utiles dans l’interface GitLab
Corriger les causes les plus fréquentes

Dans quel contexte ?

En environnement réel, ces incidents arrivent souvent juste avant une mise en production. Le stress monte parce que le pipeline n’avance pas, mais personne ne sait pourquoi. Sans méthode claire, l’équipe perd du temps à relancer des pipelines inutiles.

Ce lab vous sert pour :

identifier un tag runner mal configuré
détecter une règle workflow trop restrictive
comprendre pourquoi un job ne démarre jamais alors que le code est correct

Prérequis

Lab 10 — Rapports qualité terminé
Avoir lu Debug pending et Debug skip

Point de départ

Basculez sur la branche du lab
Fenêtre de terminal
```
cd pipeline-craft
git checkout starter/lab-11
```
Déclenchez un pipeline
Fenêtre de terminal
```
git push origin starter/lab-11
```
Ouvrez la vue pipeline

Vous devriez observer au moins un comportement anormal (pending ou skipped).

Le problème

Deux symptômes différents demandent deux diagnostics différents.

Un job pending signifie généralement que GitLab n’a trouvé aucun runner compatible (tags, disponibilité, quota). Un pipeline skipped vient souvent des rules ou du workflow qui ne matchent pas la source courante.

L’exercice

Étape 1 — Traiter un job pending

Ouvrez le job pending
Vérifiez les messages d’assignation runner
Contrôlez les tags du job dans .gitlab-ci.yml
```
my-job:
  tags:
    - docker
```
Vérifiez qu’un runner actif possède ce tag

Dans GitLab : Settings > CI/CD > Runners. Si aucun runner n’a le tag requis, le job restera pending indéfiniment.

Étape 2 — Traiter un pipeline skipped

Ouvrez le .gitlab-ci.yml
Relisez le bloc workflow: rules
Comparez avec votre contexte réel (push, merge_request_event, tag)

Exemple de règle trop restrictive :
```
workflow:
  rules:
    - if: $CI_COMMIT_TAG
```
Dans cet exemple, un push standard est skip par design. Il faut ajouter les cas attendus.

Étape 3 — Corriger puis valider

Ajustez tags/rules
Validez avec glab ci lint
Fenêtre de terminal
```
glab ci lint .gitlab-ci.yml
```

Poussez et observez un run normal

git add .gitlab-ci.yml
git commit -m "ci: fix pending/skipped root causes"
git push origin starter/lab-11

Vérification

Le job pending est pris par un runner
Le pipeline n’est plus skipped de façon inattendue
Les règles couvrent les sources de pipeline attendues
La correction est reproductible sur un nouveau push

Pièges fréquents

Un job pending n’est pas un job cassé. C’est un job en attente de runner. Chercher une erreur applicative dans le code ne sert donc à rien à ce stade. Il faut d’abord résoudre l’assignation runner.

Pour skipped, le piège est de penser à un bug GitLab. Dans la majorité des cas, c’est le comportement voulu par vos règles, même si vous ne l’aviez pas anticipé.

À retenir

pending et skipped sont des statuts de pilotage CI, pas des erreurs applicatives
Les tags runner doivent correspondre exactement
workflow: rules décide si le pipeline démarre
Une checklist simple évite les diagnostics au hasard

Prochaines étapes

Lab 12 — Accélérer le pipeline Réduire fortement la durée de pipeline

Guide : debug pending Méthode détaillée côté runners

Guide : debug skipped Méthode détaillée côté rules