La prod suit à nouveau les images publiées : les stacks passent au tag :main #1

2026-07-26T22:00:06+02:00

Gato commented

2026-07-26 22:00:06 +02:00

Ce qui s'est passé

Le déploiement de 8c05a8a est parti correctement (build ✅, appel Watchtower ✅ HTTP 200), mais la vérification post-déploiement a échoué : le site servait toujours a70e0e4, un build du 25 juillet, soit 79 commits de retard.

Cause

Les stacks luz/ et dev-luz/ épinglaient git.goutailler-olivier.com/luz/luz-*:develop.

La CI de l'app (client/app/.gitea/workflows/images.yml) ne se déclenche plus que sur main et publie sha-<court>, main et latest — plus rien ne pousse :develop. Le tag est donc figé sur le dernier build develop, a70e0e4.

Panne parfaitement silencieuse : Watchtower répondait 200 à /v1/update, comparait :develop à lui-même, ne trouvait rien de neuf et ne recréait aucun conteneur. Seule la vérification post-déploiement de la CI l'a révélée — elle a fait exactement son travail.

Correctif

Les quatre images (backend + webapp, prod et dev-luz) visent :main. Les en-têtes des deux stacks rappellent que ce tag doit rester celui que publie images.yml : changer l'un impose de changer l'autre, faute de quoi le déploiement redevient muet.

Les trois compose modifiés sont validés syntaxiquement (yaml.safe_load).

⚠️ Après le merge : une action manuelle sur le serveur

Watchtower ne change pas le tag épinglé d'un conteneur — il ne fait que retirer le même tag. Le changement de tag doit donc être appliqué à la main :

cd <infra>/luz     && git pull && docker compose up -d
cd <infra>/dev-luz && git pull && docker compose up -d

Ensuite seulement le cycle automatique reprend. À vérifier après coup :

curl -s https://luz.goutailler-olivier.com/version.json   # attendu : {"sha":"8c05a8a"}
curl -s https://luz.goutailler-olivier.com/api/version

Point à trancher (hors correctif)

Prod et dev-luz tirent désormais la même image :main, ce qui prive dev-luz de son rôle de pré-production — la CI ne construit plus rien depuis develop. Si tester avant la mise en production reste souhaitable, il faudra faire publier à images.yml un tag depuis develop et y ramener dev-luz. Volontairement laissé hors de cette PR, qui se limite à débloquer la prod.

🤖 Generated with Claude Code

## Ce qui s'est passé Le déploiement de `8c05a8a` est parti correctement (build ✅, appel Watchtower ✅ HTTP 200), mais la vérification post-déploiement a échoué : le site servait toujours `a70e0e4`, un build du **25 juillet**, soit **79 commits** de retard. ## Cause Les stacks `luz/` et `dev-luz/` épinglaient `git.goutailler-olivier.com/luz/luz-*:develop`. La CI de l'app (`client/app/.gitea/workflows/images.yml`) ne se déclenche plus que sur `main` et publie `sha-<court>`, `main` et `latest` — **plus rien ne pousse `:develop`**. Le tag est donc figé sur le dernier build develop, `a70e0e4`. Panne parfaitement silencieuse : Watchtower répondait 200 à `/v1/update`, comparait `:develop` à lui-même, ne trouvait rien de neuf et ne recréait aucun conteneur. Seule la vérification post-déploiement de la CI l'a révélée — elle a fait exactement son travail. ## Correctif Les quatre images (backend + webapp, prod et dev-luz) visent `:main`. Les en-têtes des deux stacks rappellent que ce tag doit rester celui que publie `images.yml` : changer l'un impose de changer l'autre, faute de quoi le déploiement redevient muet. Les trois compose modifiés sont validés syntaxiquement (`yaml.safe_load`). ## ⚠️ Après le merge : une action manuelle sur le serveur Watchtower ne change pas le tag épinglé d'un conteneur — il ne fait que retirer *le même* tag. Le changement de tag doit donc être appliqué à la main : ``` cd <infra>/luz && git pull && docker compose up -d cd <infra>/dev-luz && git pull && docker compose up -d ``` Ensuite seulement le cycle automatique reprend. À vérifier après coup : ``` curl -s https://luz.goutailler-olivier.com/version.json # attendu : {"sha":"8c05a8a"} curl -s https://luz.goutailler-olivier.com/api/version ``` ## Point à trancher (hors correctif) Prod et dev-luz tirent désormais la **même** image `:main`, ce qui prive dev-luz de son rôle de pré-production — la CI ne construit plus rien depuis `develop`. Si tester avant la mise en production reste souhaitable, il faudra faire publier à `images.yml` un tag depuis `develop` et y ramener dev-luz. Volontairement laissé hors de cette PR, qui se limite à débloquer la prod. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Gato added 1 commit 2026-07-26 22:00:06 +02:00

fix(luz): les stacks suivent le tag :main, publié par la CI 5558c206a0

La prod servait encore a70e0e4 (25/07) alors que main en etait a 79 commits
plus loin : les stacks luz et dev-luz epinglaient « :develop », un tag que la
CI de l'app ne pousse plus depuis qu'elle ne se declenche que sur main
(images.yml publie sha-<court>, main et latest).

Rien ne le signalait : Watchtower repondait bien 200 a /v1/update, ne trouvait
aucune image plus recente pour « :develop » et ne recreait donc rien. Seule la
verification post-deploiement de la CI a fini par le dire.

Les quatre images (backend + webapp, prod et dev-luz) visent desormais « :main ».
Les en-tetes des deux stacks rappellent que ce tag doit rester celui que publie
images.yml, changer l'un imposant de changer l'autre.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Gato merged commit 23ce5c86e1 into main

2026-07-26 22:02:44 +02:00

Gato deleted branch fix/stacks-luz-suivent-le-tag-main

2026-07-26 22:02:45 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Gato/Infra#1