PG18 de retour, mises à jour nocturnes, tests de reprise et documentation

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.

docs/decisions/0001-image-vectorchord-et-timescaledb-compile.md

@@ -0,0 +1,32 @@
+# 0001 — Image de VectorChord en base, TimescaleDB compilé, PostGIS par apt
+
+## Contexte
+
+L'image doit réunir PostgreSQL, TimescaleDB, VectorChord, pgvector et PostGIS, pour plusieurs
+versions majeures de PostgreSQL. TensorChord publie `tensorchord/vchord-postgres`, qui
+contient déjà PostgreSQL, VectorChord et pgvector, construite sur l'image officielle
+`postgres` (Debian 12, dépôt de paquets PGDG).
+
+## Décision
+
+- L'image part de `tensorchord/vchord-postgres:pgN-vX.Y.Z`.
+- TimescaleDB est compilé depuis l'étiquette Git de sa version, dans une étape séparée. Seuls
+  ses bibliothèques et ses scripts SQL passent dans l'image finale.
+- PostGIS est installé par le paquet `postgresql-N-postgis-3` du dépôt PGDG.
+- Les extensions sont créées à l'initialisation de la base par un script de
+  `/docker-entrypoint-initdb.d/`, et la commande de l'image précharge `timescaledb` et
+  `vchord`.
+
+## Conséquences
+
+- Le même Dockerfile sert toutes les versions de PostgreSQL pour lesquelles TensorChord
+  publie une image.
+- Une construction sans cache compile TimescaleDB, ce qui prend plusieurs minutes par
+  version.
+- Les outils de compilation ne sont pas dans l'image publiée.
+- Variables d'environnement, point d'entrée et emplacement des données sont ceux de l'image
+  officielle `postgres`.
+
+## Attestée par
+
+`Dockerfile` ; `init-extensions.sh` ; `tests/test-*.sql`.

docs/decisions/0002-paquets-a-jour-et-en-tetes-du-serveur.md

@@ -0,0 +1,38 @@
+# 0002 — Paquets mis à niveau à la construction, en-têtes épinglés sur le serveur
+
+## Contexte
+
+L'image de base n'est republiée qu'à chaque version de VectorChord. Entre deux, son
+PostgreSQL prend du retard sur les versions mineures et les correctifs de sécurité : une
+image de base contenait PostgreSQL 18.3 quand le dépôt PGDG en était à 18.6, avec une
+trentaine d'autres paquets en retard.
+
+La compilation de TimescaleDB installe les en-têtes du serveur par apt, donc dans la
+dernière version. Compilé avec des en-têtes 18.6 puis chargé par un serveur 18.3,
+TimescaleDB échouait à la création de l'extension (`undefined symbol: palloc0_mul`), sans
+erreur à la compilation. PostgreSQL 18 avait été retiré de la CI pour cette raison.
+
+## Décision
+
+- Une étape `base`, commune à la compilation et à l'image finale, met tous les paquets à
+  niveau (`apt-get upgrade --with-new-pkgs`). Le serveur publié est donc à la dernière
+  version mineure.
+- L'étape de compilation installe les en-têtes dans la version exacte du serveur installé,
+  lue par `dpkg-query`, et non dans la dernière disponible.
+- La couche de mise à niveau porte une clé de cache, l'argument `APT_REFRESH`.
+
+## Conséquences
+
+- PostgreSQL 18 est de nouveau construit et publié.
+- Serveur et en-têtes ne peuvent plus diverger : si la version voulue des en-têtes n'est
+  plus dans le dépôt, la construction échoue au lieu de produire une image qui ne charge
+  pas TimescaleDB.
+- La variable d'environnement `PG_VERSION` héritée de l'image de base n'est plus la version
+  du serveur.
+- Sans changement de `APT_REFRESH`, le cache garde la mise à niveau telle qu'elle a été
+  faite : c'est la CI qui décide quand la rejouer
+  ([0005](0005-mises-a-jour-nocturnes-pilotees-par-apt.md)).
+
+## Attestée par
+
+`Dockerfile` (étapes `base` et `builder`) ; commit `dcf4169`, qui avait retiré PostgreSQL 18.

docs/decisions/0003-versions-de-timescaledb-et-vectorchord-epinglees.md

@@ -0,0 +1,32 @@
+# 0003 — Versions de TimescaleDB et de VectorChord épinglées
+
+## Contexte
+
+TimescaleDB nomme sa bibliothèque d'après sa version (`timescaledb-2.28.3.so`), et une base
+retient la version de l'extension qu'elle a installée. L'image ne contient que la
+bibliothèque de la version compilée. Démarrée sur une base créée avec une autre version,
+elle refuse toute requête (`could not access file "$libdir/timescaledb-2.28.3"`) jusqu'à
+l'exécution de `ALTER EXTENSION timescaledb UPDATE`. Le serveur, lui, démarre et répond à
+`pg_isready`.
+
+Les versions mineures de PostgreSQL, pgvector et PostGIS n'ont pas cet effet : une base
+existante redémarre sur la nouvelle image sans intervention.
+
+## Décision
+
+- `TIMESCALEDB_VERSION` et `VCHORD_VERSION` sont écrits dans le Dockerfile. La CI ne les fait
+  jamais avancer d'elle-même.
+- Les changer est un commit, précédé du test de reprise et d'un avertissement aux
+  exploitants ([exploitation/publication.md](../exploitation/publication.md)).
+- Tout le reste suit apt ([0002](0002-paquets-a-jour-et-en-tetes-du-serveur.md)).
+
+## Conséquences
+
+- Aucune republication automatique ne peut rendre une base inutilisable.
+- TimescaleDB et VectorChord prennent du retard tant que personne ne change leur version.
+- Le test de reprise de `tests.sh` commence par mettre les extensions à niveau : il vérifie
+  que la procédure fonctionne, pas que la base repart sans elle.
+
+## Attestée par
+
+`Dockerfile` ; `tests/reprise-2-controle.sql`.

docs/decisions/0004-ci-sans-action-externe.md

@@ -0,0 +1,36 @@
+# 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.

docs/decisions/0005-mises-a-jour-nocturnes-pilotees-par-apt.md

@@ -0,0 +1,42 @@
+# 0005 — Mises à jour nocturnes, déclenchées par ce qu'apt propose
+
+Complète [0002](0002-paquets-a-jour-et-en-tetes-du-serveur.md) et
+[0004](0004-ci-sans-action-externe.md).
+
+## 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](0003-versions-de-timescaledb-et-vectorchord-epinglees.md)).
+
+## 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`).

docs/decisions/0006-latest-reste-sur-postgresql-17.md

@@ -0,0 +1,26 @@
+# 0006 — `latest` reste sur PostgreSQL 17
+
+## Contexte
+
+L'image est publiée pour PostgreSQL 15 à 18. `latest` désigne PostgreSQL 17, et la base de
+Health l'utilise, avec un volume monté sur `/var/lib/postgresql/data`. Les données d'une
+version majeure ne sont pas lisibles par la suivante, et l'image `pg18` attend son volume sur
+`/var/lib/postgresql`.
+
+## Décision
+
+- `latest` reste une seconde étiquette de `pg17`. L'arrivée de `pg18` ne la déplace pas.
+- Un nouveau projet choisit une étiquette `pgN` explicite.
+
+## Conséquences
+
+- Aucun exploitant ne change de version majeure en tirant `latest`.
+- `latest` ne désigne pas la version la plus récente de PostgreSQL.
+- Déplacer `latest` demandera une nouvelle décision, après migration des bases qui
+  l'utilisent (`pg_upgrade`, ou sauvegarde et restauration) et changement de leur point de
+  montage.
+
+## Attestée par
+
+`.gitea/workflows/docker.yml` (étape « Tag latest ») ; `docker-compose.yml` de
+health-workspace.