maxime.killinger
7de55c5655
🚀 Docker Build and Push / build-and-push (15) (push) Successful in 5m29s
🚀 Docker Build and Push / build-and-push (16) (push) Successful in 6m10s
🚀 Docker Build and Push / build-and-push (17) (push) Successful in 5m20s
🚀 Docker Build and Push / build-and-push (18) (push) Successful in 5m21s
Image - Étape `base` commune : tous les paquets sont mis à niveau (PostgreSQL à la dernière mineure, pgvector, Debian). L'image de base de VectorChord restait figée à la version de sa publication. - En-têtes du serveur épinglés sur la version du serveur installé. PG18 avait été retiré parce que TimescaleDB, compilé avec des en-têtes 18.6, était chargé par un serveur 18.3 (`undefined symbol: palloc0_mul`). - Sonde de santé avec l'utilisateur et la base du conteneur : en `postgres`, elle écrivait une erreur FATAL au journal dès que POSTGRES_USER était défini. - Label `base.name` corrigé : il reprenait la version du paquet au lieu de la version majeure. CI - PG18 ajouté à la matrice. - Exécution nocturne : apt est interrogé dans l'image publiée ; elle n'est reconstruite et republiée que s'il lui reste des mises à jour, sinon elle est seulement testée. Lancement manuel possible. - `docker-build.yml` supprimé : l'ancien workflow à actions externes tournait encore à chaque push, en double de `docker.yml`. - `paths-ignore` : un push de documentation seule ne lance pas la CI. - Labels `version`, `url` et `fr.killinger.apt-refresh`. Tests - `tests.sh`, la même commande en local et en CI : utilisateur et base autres que `postgres`, version majeure du serveur, présence des cinq extensions, redémarrage, et reprise d'une base créée par l'image publiée. Documentation - README en vitrine, CLAUDE.md, docs/architecture.md, docs/exploitation/publication.md, six décisions, docs/a-faire.md.
37 lines
1.9 KiB
Markdown
37 lines
1.9 KiB
Markdown
# 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.
|