fix(infra): smoke waits on durable services, not the whole project (refs #30)
All checks were successful
CI / lint (pull_request) Successful in 50s
CI / build (pull_request) Successful in 42s
CI / unit (pull_request) Successful in 50s
CI / compose-smoke (pull_request) Successful in 4m52s

Run 28 got the full stack healthy but `compose-smoke` still failed. The last
compose line before the error was:

  container infra-flowable-init-1 exited (0)

`docker compose up --wait` treats a service that exits as a failure of the
"stay running" condition unless something depends on it via
`service_completed_successfully`. oz-init/nrc-init are fine (openzaak/nrc-web
depend on them), but flowable-init deploys the BPMN and exits 0 with no
dependant, so whole-project `--wait` failed the instant it finished — even
though everything else was healthy and nrc-init now exits 0.

Smoke now:
  1. `up -d` starts the full stack (one-shots run + deploy as before), then
  2. `up -d --wait <WAIT_SVCS>` waits only for the durable health-checked
     services (openzaak nrc-web acl bff).

Also drops the external `curl localhost:8080/health`: the containerized CI
runner can't reach published host ports at localhost, and each service's
healthcheck already runs inside its container — so `--wait` succeeding IS the
smoke. Documented in docs/runbooks/gitea-actions-gotchas.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-25 09:03:37 +02:00
parent 12049a0f35
commit a0aa22c80b
3 changed files with 38 additions and 5 deletions

View File

@@ -16,7 +16,7 @@ and CI cannot drift:
| `lint` | `make lint``dotnet format … --verify-no-changes` | .NET 10 SDK |
| `build` | `make build``dotnet build … -c Release` | .NET 10 SDK |
| `unit` | `make unit``dotnet test … -c Release` | .NET 10 SDK |
| `compose-smoke` | `make smoke`compose up `--wait` `curl /health``down` | container engine + compose v2 |
| `compose-smoke` | `make smoke``up -d` (full stack) → `up --wait` durable services`down` | container engine + compose v2 |
All `uses:` references are absolute, tag-pinned URLs (`https://github.com/actions/checkout@v4`,
`https://github.com/actions/setup-dotnet@v4`) per CLAUDE.md §8.7 and §15 — Gitea

View File

@@ -66,6 +66,30 @@ so the SELinux `:z`/`:Z` relabel flag is no longer needed anywhere in `infra/`,
and rootless Podman no longer needs the files to be world-readable. One mechanism
(build) works on both Podman locally and Docker-in-Docker in CI.
## `--wait` fails on one-shot containers with no dependant
`docker compose up --wait` treats a service that **exits** as a failure of the
"stay up" condition — **unless** another service depends on it with
`condition: service_completed_successfully`. Our init jobs `oz-init` and
`nrc-init` are fine (`openzaak`/`nrc-web` depend on their completion), but
`flowable-init` deploys the BPMN and exits 0 with **no dependant**, so a
whole-project `--wait` fails the moment it exits — even with everything else
healthy. The symptom is a `compose-smoke` failure whose last compose line is:
```
container infra-flowable-init-1 exited (0)
```
**Fix.** The smoke does **not** `--wait` on the whole project. It starts
everything with `up -d`, then `up -d --wait <services>` only for the durable,
health-checked services (`openzaak nrc-web acl bff` — see `WAIT_SVCS` in the
`Makefile`). One-shots still run (and deploy), they just don't gate `--wait`.
This also removed the old external `curl http://localhost:8080/health` check:
the CI job runs in a container and **can't reach published host ports** at
`localhost`, and the per-service healthchecks (which run *inside* the
containers) already prove readiness, so `--wait` succeeding *is* the smoke.
## `--wait` needs an explicit timeout
`docker compose up --wait` defaults to a 60-second timeout in some Compose v2