CI pipeline

The pipeline runs on every MR, on the default branch, on production, and on tags. It has governance jobs that work out of the box, plus the stack jobs you switch on.

Stages

Stage	Jobs	What they check
lint	changelog-check, gate-selftest-parity, prepush-parity, stale-references, tooling-self-tests, plus stack linters once included	Changelog fragment present; every gate can still fail and runs before push; no stale markers; release and wt tooling self-tests
test	Stack test runners, once included	Correctness, coverage threshold
security	GitLab SAST and secret-detection components; stack license and vulnerability checks, once included	Vulnerabilities, leaked credentials, license compliance
deploy	deploy-staging and deploy-production templates, commented out	Nothing until you uncomment and fill them in

changelog-check runs on MR pipelines only. stale-references also runs on the default branch and on schedules.

Stack includes

Uncomment the relevant includes in .gitlab-ci.yml:

File	Stack	Jobs
ci/python.yml	Python	ruff lint, pytest + coverage, pip-licenses
ci/node.yml	Node.js	eslint, vitest + coverage, license-checker
ci/go.yml	Go	golangci-lint, go test, govulncheck
ci/docker.yml	Docker	kaniko build verification

Each file has configurable variables at the top (source directory, coverage threshold, image version).

When the pipeline fails

1. Run /ci-debug with the pipeline or MR number — it fetches logs, identifies the root cause, and prescribes a specific fix
2. Run /fix-mr to have Claude automatically fix the issue, commit, push, and re-check (up to 3 iterations)
3. Never retry a pipeline without a code change unless the failure is clearly infrastructure-related