ci: lance Postgres en conteneur d'arrière-plan (plus en `services:`) #21

Merged

kyuno merged 1 commit from ci/postgres-as-background-container into main

2026-09-03 08:40:43 +02:00

kyuno commented

2026-08-30 14:48:53 +02:00

Owner

Problème

Le runner Forgejo act ne garde pas un conteneur services: comme la même instance d'une étape de job à l'autre. Symptôme constant : prisma migrate deploy réussit (« The following migration(s) have been applied »), puis le beforeAll de Mocha frappe un Postgres vide :

The table `public.tech_step` does not exist in the current database.
   at async Context.beforeAll (test-support/mocha-root-hooks.ts:38:5)

Vu 3 fois aujourd'hui, dont une sur main juste après le merge de #18 (run 45) — alors que ccec30b, contenu identique, avait sa CI entièrement verte 20 min plus tôt. Ce n'est donc pas le code.

Le ci.yml contourne déjà la même limite pour tech-step-intent-service (lancé en process uvicorn & d'arrière-plan, avec un commentaire qui l'explique).

Changement

Le job test démarre Postgres lui-même :

- name: Start Postgres in the background
  run: |
    net="$(docker inspect "$(hostname)" --format '…Networks…')"
    docker run -d --name postgres --network "$net" \
      -e POSTGRES_USER=ci -e POSTGRES_PASSWORD=ci -e POSTGRES_DB=batchcooking_ci \
      postgres:16-alpine
    # attente pg_isready…

Le socket docker est déjà monté dans le conteneur de job (Binds:[/var/run/docker.sock:/var/run/docker.sock], visible dans les logs).
Le réseau (forgejo_default) est découvert depuis le conteneur de job, pas codé en dur ; échec explicite si introuvable.
Le conteneur --name postgres est joignable comme postgres → env.DATABASE_URL (hostname postgres) inchangé.
docker rm -f postgres en tête pour un éventuel reliquat d'un run précédent sur le même runner.
apt-get install … docker.io ajouté (CLI docker absent de l'image cypress/browsers).
Un seul conteneur, partagé par toutes les étapes → plus de « schéma dans un Postgres, tests dans un autre ».

Commentaires services: périmés mis à jour au passage.

Hors périmètre

Les autres flakes du runner aujourd'hui (actions/checkout / pnpm-action-setup « non-fast-forward update » ~3×) viennent du cache d'actions corrompu du runner (/data/.cache/act) — à purger côté admin du runner, rien à faire dans ce repo.

Vérification

YAML validé (yaml.safe_load), structure du job test OK, services: bien retiré.
Le comportement réel ne peut se vérifier qu'en faisant tourner la CI — c'est l'objet de cette PR. Risque résiduel : le postinst de docker.io qui tenterait un systemctl (no-op en conteneur, apt sort quand même 0) ; à surveiller sur le 1er run.

🤖 Generated with Claude Code

## Problème Le runner Forgejo `act` ne garde **pas** un conteneur `services:` comme *la même* instance d'une étape de job à l'autre. Symptôme constant : `prisma migrate deploy` réussit (« The following migration(s) have been applied »), puis le `beforeAll` de Mocha frappe un Postgres **vide** : ``` The table `public.tech_step` does not exist in the current database. at async Context.beforeAll (test-support/mocha-root-hooks.ts:38:5) ``` Vu **3 fois aujourd'hui**, dont une sur `main` juste après le merge de #18 (run 45) — alors que `ccec30b`, **contenu identique**, avait sa CI entièrement verte 20 min plus tôt. Ce n'est donc pas le code. Le `ci.yml` contourne **déjà** la même limite pour `tech-step-intent-service` (lancé en process `uvicorn &` d'arrière-plan, avec un commentaire qui l'explique). ## Changement Le job `test` démarre Postgres lui-même : ```yaml - name: Start Postgres in the background run: | net="$(docker inspect "$(hostname)" --format '…Networks…')" docker run -d --name postgres --network "$net" \ -e POSTGRES_USER=ci -e POSTGRES_PASSWORD=ci -e POSTGRES_DB=batchcooking_ci \ postgres:16-alpine # attente pg_isready… ``` - Le socket docker est **déjà monté** dans le conteneur de job (`Binds:[/var/run/docker.sock:/var/run/docker.sock]`, visible dans les logs). - Le réseau (`forgejo_default`) est **découvert** depuis le conteneur de job, pas codé en dur ; échec explicite si introuvable. - Le conteneur `--name postgres` est joignable comme `postgres` → `env.DATABASE_URL` (hostname `postgres`) **inchangé**. - `docker rm -f postgres` en tête pour un éventuel reliquat d'un run précédent sur le même runner. - `apt-get install … docker.io` ajouté (CLI docker absent de l'image `cypress/browsers`). - Un seul conteneur, partagé par toutes les étapes → plus de « schéma dans un Postgres, tests dans un autre ». Commentaires `services:` périmés mis à jour au passage. ## Hors périmètre Les autres flakes du runner aujourd'hui (`actions/checkout` / `pnpm-action-setup` « non-fast-forward update » ~3×) viennent du **cache d'actions corrompu du runner** (`/data/.cache/act`) — à purger côté admin du runner, rien à faire dans ce repo. ## Vérification - YAML validé (`yaml.safe_load`), structure du job `test` OK, `services:` bien retiré. - Le comportement réel ne peut se vérifier qu'en faisant tourner la CI — c'est l'objet de cette PR. Risque résiduel : le postinst de `docker.io` qui tenterait un `systemctl` (no-op en conteneur, `apt` sort quand même 0) ; à surveiller sur le 1er run. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kyuno added 1 commit 2026-08-30 14:48:54 +02:00

ci: lance Postgres en conteneur d'arriere-plan, plus en services:

CI / lint (push) Successful in 1m6s

Details

CI / build (push) Successful in 1m33s

Details

CI / e2e (push) Successful in 7m29s

Details

CI / intent-service-test (push) Successful in 11m51s

Details

CI / test (push) Successful in 21m11s

Details

89fedc93e2

Le runner Forgejo `act` ne garde pas un conteneur `services:` comme *la
meme* instance d'une etape a l'autre : `prisma migrate deploy` posait le
schema dans un Postgres, puis le `beforeAll` de Mocha en frappait un vide
(« table … does not exist » juste apres « migrations successfully
applied »). Trois occurrences en une journee, dont une sur `main` apres le
merge de #18 — code identique a `ccec30b` qui, lui, etait vert.

Le job `test` demarre desormais Postgres lui-meme via `docker run -d`
(socket docker deja monte dans le conteneur de job), sur le reseau du job
decouvert dynamiquement, joignable comme `postgres` — exactement la meme
posture « vraie dependance lancee par le job » que l'etape uvicorn de
`tech-step-intent-service` juste en dessous, que `services:` ne pouvait
deja pas couvrir. Un seul conteneur, partage par toutes les etapes.

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