# 0004 — CI sans action externe, cache du démon, une construction par version

## Contexte

La CI téléchargeait depuis GitHub, à chaque job, quatre actions (`checkout`,
`setup-buildx`, `login`, `build-push`), une vingtaine de secondes chacune, pour des
opérations que l'image du runner sait faire avec `git` et `docker`. `setup-buildx` créait un
constructeur neuf, sans cache : TimescaleDB était recompilé à chaque job, 7 à 9 minutes par
version. L'image était construite jusqu'à trois fois : pour les tests, pour la publication,
puis pour `latest`. Tout push relançait la CI, même quand il ne touchait que la documentation.

## Décision

- Récupération du seul commit concerné par `git fetch --depth 1`, connexion au registre par
  `docker login`, construction par `docker build --pull` avec le démon Docker du runner,
  dont le cache persiste d'un job à l'autre.
- Une seule construction par version : l'image testée est celle qui est poussée, et `latest`
  est une seconde étiquette de la même image.
- Les tests sont une commande du dépôt, `tests.sh`, la même en local.
- `paths-ignore` sur `**.md` et `docs/**` : un push de documentation seule ne lance pas la CI.
- Cache de construction borné à 8 Go, images sans étiquette supprimées en fin de job.

## Conséquences

- La CI ne dépend plus de la disponibilité de GitHub pour ses actions. Elle en dépend encore
  pour le code source de TimescaleDB, quand il faut le recompiler.
- La compilation n'est rejouée que si l'image de base, les paquets ou la version de
  TimescaleDB changent.
- Le runner doit donner accès à un démon Docker, ce qui est le cas du runner commun aux
  dépôts de Health et aux sites.
- Le cache est partagé avec les autres dépôts du runner, chacun le bornant à 8 Go.

## Attestée par

`.gitea/workflows/docker.yml` ; commit `2a0f84e` ; la même décision dans nk-environnement
(`0011-ci-sans-action-externe.md`) et dans les dépôts de Health.