Git dans une chaîne CI/CD

Chaque job de pipeline commence par un clone. Sur un dépôt de dix ans, cloner l'historique complet à chaque exécution coûte des minutes — multipliées par le nombre de jobs, par le nombre de commits par jour.

Le clone superficiel

- uses: actions/checkout@v4
  with:
    fetch-depth: 1        # défaut : un seul commit

--depth=1 ne récupère que le dernier commit. Le gain est réel, et c'est pourquoi c'est le comportement par défaut de la plupart des forges.

Le bon réglage est donc par job, pas par dépôt : 1 pour un job qui construit, 0 pour un job qui compare, versionne ou analyse l'historique.

Ne reconstruire que ce qui a changé

Dans un monorepo, reconstruire les vingt services à chaque commit est le premier gaspillage à supprimer.

$ git diff --name-only origin/main...HEAD
services/api/src/routes.ts
services/api/package.json

Les trois points sont significatifs : A...B compare B avec l'ancêtre commun des deux, c'est-à-dire ce que la branche a réellement changé. Avec deux points, A..B compare les deux sommets — le résultat inclut alors ce qui a bougé sur main entre-temps, et le job reconstruit des services que personne n'a touchés.

À partir de cette liste, un job décide s'il doit s'exécuter. C'est ce qui rend un monorepo tenable — la contrepartie d'outillage annoncée dans Architectures de pipelines.

Identifier ce qu'on produit

$ git rev-parse --short HEAD
7f3k9q2
$ git describe --tags
v1.2.0-14-g7f3k9q2      # 14 commits après v1.2.0

Étiqueter une image avec le SHA du commit donne une correspondance exacte et immuable entre un artefact et le code qui l'a produit. C'est ce qui permet, six mois plus tard, de répondre à « quelle version tourne en production, et d'où vient-elle ? ».

git describe dérive une version lisible depuis la dernière étiquette. Les deux se complètent : le SHA identifie, la description raconte. Aucun des deux ne fonctionne avec fetch-depth: 1.

Les pièges classiques

Un runner place le dépôt en tête détachée sur le commit à construire : git branch --show-current ne renvoie rien. Un script qui suppose être sur une branche échoue là, alors qu'il fonctionne sur un poste de développement. Le nom de la référence vient des variables de la forge, pas de Git.

Le jeton d'authentification utilisé pour cloner est souvent inscrit dans la configuration du dépôt cloné. Un job ultérieur qui affiche git config --list dans ses journaux peut donc l'exposer — c'est un cas concret des identités traitées dans Sécuriser une pipeline.