CI and deployment pipeline

The repository checks changes locally and in GitHub Actions. The Build workflow validates code, tests it, builds a container image and deploys successful staging and main builds to Azure. Other workflows handle releases, staging data and scheduled maintenance.

Local checksCopy Anchor Link

.pre-commit-config.yaml defines syntax, merge-conflict, large-file and secret checks, followed by Ultracite checks on staged code, a TypeScript check for staged TypeScript changes, integration tests for relevant code changes, and file cleanup. Run these checks on demand with uv tool run pre-commit run --all-files, as described in the pull request guide. Integration tests require the dedicated local PostgreSQL test container.

The repository's prepare script points Git at .githooks/. Its pre-push hook runs pnpm lint and pnpm typecheck when a push targets staging or main. The hook is a local check; the GitHub workflows provide the remote result.

Build workflowCopy Anchor Link

.github/workflows/build.yaml runs on pull requests, matching pushes to main or staging, and manual dispatch. The validate job runs Ultracite and TypeScript. It runs pnpm docs:generate and fails if public/openapi.json changes. It also runs pnpm audit --audit-level=high, currently with continue-on-error, so an audit finding does not by itself fail that job.

The test job runs unit tests with coverage, integration tests against PostgreSQL, and Playwright end-to-end tests. For pull requests, a changed-path check can skip the expensive test job when no code-relevant path changed. The Structural Quality (blocking) job uses fallow on pull requests and consumes merged unit and integration coverage. .github/workflows/fallow.yml is a retired manual-only placeholder; the active gate is in build.yaml.

After validation and tests succeed, push and manual-dispatch runs build and push a Docker image to GHCR. Pull requests do not build an image. For main and staging, its deployment job calls the corresponding Azure webhook and then checks /api/health. The workflow's image name is alan-turing-institute/assuranceplatform/tea-app. Check the Docker deployment guide for the separate compose-file image setting.

Release and staging dataCopy Anchor Link

The Release workflow runs when a successful Build workflow completes on main. It runs semantic-release, which uses conventional commit history for versioning and release notes, then merges the release commit back into staging. It is not triggered by a manually created version tag. The versioning guide explains the release rules.

Seed staging database runs after a successful staging Build or on manual dispatch. It checks out staging, resets and migrates the staging database, grants the application database user access and runs the seed script. This is a staging reset, so do not treat it as a general production migration procedure.

Scheduled workflowsCopy Anchor Link

The workflow directory also contains Purge expired trash, Sweep health staleness, Data retention sweep and Cleanup PR Docker Images. Each has a schedule and a manual trigger. The first three call application cron routes using a cron secret; image cleanup acts on the container registry. The retired fallow file remains in the directory, making eight workflow files in total, but seven active workflows.