30887c066b
Le service api clonait le dépôt et compilait le JAR sur le serveur à chaque « docker compose build » (Dockerfile.api + secret ssh_key + CACHEBUST). La prod rebuildait donc ce que la CI avait déjà buildé, sans garantie que les deux partent du même commit — et aucune image publiée n'atteignait jamais la prod. Elle tire maintenant …/bonsai-api:main et porte le label watchtower.enable : le redéploiement suit tout seul chaque merge sur main, comme pour Luz. Le webapp, lui, continue d'être buildé depuis les sources — d'où le secret ssh_key conservé. Prérequis : de quoi tirer les images privées de l'org Bonsai. Le PAT de Watchtower n'a aujourd'hui le scope read:package que sur Luz ; sans extension à Bonsai, le pull échoue en silence (/v1/update répond 200, la prod ne bouge pas). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
14 lines
554 B
Bash
Executable File
14 lines
554 B
Bash
Executable File
#!/bin/bash
|
|
#
|
|
# Déploiement manuel de la stack Bonsai.
|
|
#
|
|
# L'API n'est plus buildée ici : son image est publiée par la CI du dépôt
|
|
# Bonsai-api à chaque merge sur main, et Watchtower recrée le conteneur tout seul.
|
|
# Ce script sert donc au premier démarrage, à un changement de la stack ou à un
|
|
# redéploiement forcé — « pull » va chercher la dernière image de l'API, « build »
|
|
# ne concerne plus que le webapp (toujours compilé depuis les sources).
|
|
|
|
docker compose pull
|
|
CACHEBUST=$(date +%s) docker compose build
|
|
docker compose up -d
|