CI

The pipeline is defined in the application repository's .gitlab-ci.yml, which consumes versioned components from the yotoshelf/pipeline catalog and adds a few inline jobs. That file names every component and every pin it uses; read it there rather than a copy here, which would go stale on the next bump.

What just check runs

The local just check recipe is the mirror of the pipeline's gates. The list below is AGENTS.md read from the repository when this page was built.

After every change:

just check-fast

just check-fast is the inner loop (no network, no race detector); run the full just check, which mirrors CI, before pushing.

just check runs the same commands as these CI jobs:

• check:go — golangci-lint, go test ./... -race -shuffle=on, go build, govulncheck, and the Go half of scripts/check-licenses.sh
• check:file-size — scripts/check-file-size.sh (Go and Svelte LOC caps)
• check:frontend — npm ci, npm run build, and the raw-fetch() layering gate
• check:frontend-types — astro check over .astro, .svelte and .ts, and the npm half of scripts/check-licenses.sh
• check:i18n — scripts/check-i18n.sh (no hardcoded English strings)
• check:generated — just generate then git diff: sqlc output and types.ts must not move

Four CI jobs have no local equivalent and can only fail in the pipeline: check:secrets, check:hygiene, build:container and e2e:playwright. (just e2e runs the same specs, but is not part of just check — it takes minutes.) A green just check means those four are the only jobs still unproven.

Running just check before pushing is the fastest way to catch failures without burning CI minutes.

Container image

Container builds happen in GitLab CI on main. The Containerfile uses a three-stage build: Node (frontend) → Go (binary) → Alpine (runtime + ffmpeg).

To run the published image rather than build one, see Quick Start.