ci(release): publie les images Docker sur le registre Forgejo #145

Merged

kyuno merged 1 commit from feat/release-push-docker-images into main

2026-09-10 22:23:43 +02:00

kyuno commented

2026-09-10 22:03:53 +02:00

Owner

Contexte

La CI de release ne poussait aucune image : release.yml's sanity-build faisait un docker build -f apps/api/Dockerfile . sans push, et Portainer reconstruisait tout lui-même depuis le dépôt Git.

Cette PR fait construire et publier les 3 images de service sur le registre de conteneurs intégré à Forgejo, et recâble docker-compose.yml + la doc pour pouvoir tirer ces images pré-construites.

Changements

.github/workflows/release.yml

permissions: + packages: write (garde contents: write)
sanity-build → build-and-push-images : docker login sur le registre Forgejo (${GITHUB_SERVER_URL} sans le schéma) avec le token Actions du run, puis build + push de :
- git.dev.kyuno.fr/kyuno/batchcooking-app — apps/api/Dockerfile
- git.dev.kyuno.fr/kyuno/batchcooking-intent-service — services/tech-step-intent-service/Dockerfile
- git.dev.kyuno.fr/kyuno/batchcooking-llm-worker — services/tech-step-llm-worker/Dockerfile
taguées ${GITHUB_REF_NAME} (ex. v0.2.4) et latest. Un push réussi vaut aussi la vérification « ça build encore » que faisait sanity-build (qui ne couvrait que l'API).
Job séquentiel, pas de matrix : 3 docker build concurrents saturent le daemon Docker du runner unique (ressource contendue d'après la mémoire projet ci-forgejo-runner-constraints) sans gain réel pour une release.
forgejo-release : needs: mis à jour.

docker-compose.yml — image: git.dev.kyuno.fr/kyuno/batchcooking-*:${IMAGE_TAG:-latest} ajouté aux 3 services buildables, build: gardé en repli local. docker compose pull récupère les images pré-construites ; docker compose up/build retombe sur un build local si absentes. Portainer peut donc passer en mode pull ou garder son build-depuis-Git — les deux marchent avec le même fichier.

.env.example — # IMAGE_TAG=latest documenté.

README.md — section « Pas de registre d'image » réécrite ; sous-section Release corrigée (4 jobs, noms à jour — elle disait « trois jobs » / github-release).

Vérification

python -c "import yaml; yaml.safe_load(...)" sur release.yml et docker-compose.yml : OK
Plus aucune référence périmée à sanity-build (les 2 restantes sont des commentaires historiques volontaires)
Pas de docker CLI dans l'environnement de dev (cf. mémoire dev-environment-gotchas) → pas de smoke-test build/login local possible
Validation réelle = prochain tag vX.Y.Z après merge : suivre le job build-and-push-images, confirmer les 3 paquets sur git.dev.kyuno.fr/kyuno/-/packages (tag + latest), puis IMAGE_TAG=vX.Y.Z docker compose pull.

Repli si le token de run ne peut pas pousser de paquet (politique d'instance) : créer un PAT Forgejo write:package, l'ajouter en secret de dépôt, et l'utiliser à la place de secrets.GITHUB_TOKEN dans le docker login (une ligne à changer, noté dans le commentaire du bloc permissions:).

🤖 Generated with Claude Code

## Contexte La CI de release ne poussait **aucune image** : `release.yml`'s `sanity-build` faisait un `docker build -f apps/api/Dockerfile .` **sans push**, et Portainer reconstruisait tout lui-même depuis le dépôt Git. Cette PR fait construire et publier les **3 images de service** sur le **registre de conteneurs intégré à Forgejo**, et recâble `docker-compose.yml` + la doc pour pouvoir tirer ces images pré-construites. ## Changements **`.github/workflows/release.yml`** - `permissions:` + `packages: write` (garde `contents: write`) - `sanity-build` → **`build-and-push-images`** : `docker login` sur le registre Forgejo (`${GITHUB_SERVER_URL}` sans le schéma) avec le token Actions du run, puis build + push de : - `git.dev.kyuno.fr/kyuno/batchcooking-app` — `apps/api/Dockerfile` - `git.dev.kyuno.fr/kyuno/batchcooking-intent-service` — `services/tech-step-intent-service/Dockerfile` - `git.dev.kyuno.fr/kyuno/batchcooking-llm-worker` — `services/tech-step-llm-worker/Dockerfile` taguées `${GITHUB_REF_NAME}` (ex. `v0.2.4`) **et** `latest`. Un push réussi vaut aussi la vérification « ça build encore » que faisait `sanity-build` (qui ne couvrait que l'API). - **Job séquentiel, pas de matrix** : 3 `docker build` concurrents saturent le daemon Docker du runner unique (ressource contendue d'après la mémoire projet `ci-forgejo-runner-constraints`) sans gain réel pour une release. - `forgejo-release` : `needs:` mis à jour. **`docker-compose.yml`** — `image: git.dev.kyuno.fr/kyuno/batchcooking-*:${IMAGE_TAG:-latest}` ajouté aux 3 services buildables, `build:` gardé en repli local. `docker compose pull` récupère les images pré-construites ; `docker compose up`/`build` retombe sur un build local si absentes. Portainer peut donc passer en mode *pull* **ou** garder son build-depuis-Git — les deux marchent avec le même fichier. **`.env.example`** — `# IMAGE_TAG=latest` documenté. **`README.md`** — section « Pas de registre d'image » réécrite ; sous-section Release corrigée (4 jobs, noms à jour — elle disait « trois jobs » / `github-release`). ## Vérification - `python -c "import yaml; yaml.safe_load(...)"` sur `release.yml` et `docker-compose.yml` : OK - Plus aucune référence périmée à `sanity-build` (les 2 restantes sont des commentaires historiques volontaires) - **Pas de `docker` CLI dans l'environnement de dev** (cf. mémoire `dev-environment-gotchas`) → pas de smoke-test build/login local possible - **Validation réelle = prochain tag `vX.Y.Z`** après merge : suivre le job `build-and-push-images`, confirmer les 3 paquets sur `git.dev.kyuno.fr/kyuno/-/packages` (tag + `latest`), puis `IMAGE_TAG=vX.Y.Z docker compose pull`. **Repli si le token de run ne peut pas pousser de paquet** (politique d'instance) : créer un PAT Forgejo `write:package`, l'ajouter en secret de dépôt, et l'utiliser à la place de `secrets.GITHUB_TOKEN` dans le `docker login` (une ligne à changer, noté dans le commentaire du bloc `permissions:`). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-09-10 22:03:54 +02:00

ci(release): build et push des images Docker sur le registre Forgejo

CI / lint (push) Successful in 2m48s

Details

CI / build (push) Successful in 2m55s

Details

CI / intent-service-test (push) Successful in 4m57s

Details

CI / e2e (push) Successful in 9m28s

Details

CI / test (push) Successful in 19m10s

Details

CI / build-android (push) Has been skipped

Details

7d1ee934ca

Le job `sanity-build` (build de `apps/api/Dockerfile` sans push) devient
`build-and-push-images` : `docker login` sur le registre Forgejo intégré
via le token Actions du run (`permissions: packages: write`), puis build +
push des 3 images `batchcooking-{app,intent-service,llm-worker}` taguées
`vX.Y.Z` et `latest`. Un job séquentiel plutôt qu'une matrix — 3 builds
concurrents saturent le daemon Docker du runner unique (cf. mémoire
`ci-forgejo-runner-constraints`) sans gain réel pour une release.

`docker-compose.yml` référence maintenant ces images
(`image: git.dev.kyuno.fr/kyuno/batchcooking-*:${IMAGE_TAG:-latest}`) avec
le bloc `build:` gardé en repli local — Portainer peut tirer les images
pré-construites ou continuer à builder depuis Git. `.env.example` documente
`IMAGE_TAG` ; le README (section registre + Release) est réécrit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>