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.
2.1 KiB
2.1 KiB
0005 — Mises à jour nocturnes, déclenchées par ce qu'apt propose
Contexte
Les images ne changeaient qu'à un push. Entre deux, elles ne recevaient ni version mineure de
PostgreSQL ni correctif de sécurité. Le cache persistant du runner aggrave le problème : une
couche apt-get upgrade déjà construite n'est jamais rejouée. Reconstruire sans cache chaque
nuit recompilerait TimescaleDB quatre fois et republierait quatre images identiques aux
précédentes.
Décision
- La CI tourne chaque nuit. Pour chaque version, elle tire l'image publiée et y simule
apt-get upgrade --with-new-pkgs. - S'il reste des paquets à mettre à niveau, ou si l'image n'existe pas, elle construit avec
une nouvelle clé
APT_REFRESH, teste et publie. - Sinon elle ne construit ni ne publie : elle joue les tests sur l'image publiée.
- La clé d'une image est gardée dans son label
fr.killinger.apt-refresh. Un push la reprend quand l'image publiée est à jour, pour que le cache serve. - Les versions de TimescaleDB et de VectorChord ne sont pas concernées (0003).
Conséquences
- Une version mineure de PostgreSQL ou un correctif Debian est publié la nuit qui suit son arrivée dans apt, sans intervention.
- Une nuit sans mise à jour coûte une simulation apt et les tests, par version.
- L'état de référence est l'image publiée, pas le cache du runner : un cache perdu ne provoque ni reconstruction ni publication inutiles.
- Tant qu'une reconstruction échoue aux tests, rien n'est publié et elle est retentée la nuit suivante.
- La simulation et la construction utilisent la même commande apt : après une publication, l'image n'a plus rien en attente et la nuit suivante ne reconstruit pas.
- Une republication de l'image de base sous la même étiquette n'est reprise qu'à la
prochaine reconstruction, par
--pull.
Attestée par
.gitea/workflows/docker.yml (étape « Check for updates ») ; Dockerfile (APT_REFRESH).