Le commentaire disait qu'un PAT read:package sur l'org Luz suffisait — c'était
vrai tant que Luz était seul à publier des images. La stack bonsai tire désormais
bonsai-api du même registre avec les mêmes identifiants : un PAT limité à Luz la
laisserait bloquée sur son ancienne image, sans rien signaler.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Watchtower déclenchait bien /v1/update (200) mais échouait à tirer
luz-backend/luz-webapp :develop (« unauthorized: reqPackageAccess »),
d'où Updated=0 silencieux : les conteneurs n'étaient jamais recréés et
la prod restait figée sur une ancienne image malgré une CI verte.
Le montage de /root/.docker/config.json était inopérant (le docker login
du CI a lieu sur le runner, pas sur l'hôte). On le remplace par des
identifiants de pull explicites REPO_USER/REPO_PASS (PAT read:package,
via REGISTRY_USER/REGISTRY_PASS du .env). .env.example documenté.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Gato