Skip to main content

The CI/CD GitHub Workflows

The pipeline is implemented as a set of GitHub Actions workflows in .github/workflows/. Where Deploying with the CI/CD Pipeline covers the flow, this article covers the files — what each one is for. (The authoritative, current set is the .github/workflows/ directory itself, alongside 013_core_ci_cd_plugin_strategy.md; treat this as the role map.)

Checks before merge

  • ci-staging.yml — runs the check suite on pull requests targeting staging: lint, type-check, and the unit / API / integration tests. It gates the PR, so the staging deploy can trust it rather than re-running checks.
  • ci-production.yml — runs on PRs targeting main, with the same checks plus version validation (the version-check that enforces a proper version bump and release-notes discipline — see Versioning & Cutting a Release).

The rule of thumb: checks run before merge; deploy and release run after. There's no redundant re-checking after merge.

Build

  • build-docker-images.yml — builds the API and frontend Docker images and pushes them to GHCR (ghcr.io/{org}/{repo}-api and -frontend). This is the workflow whose GHCR login and image tags you edit when forking (see Forking Circus).

Deploy

  • deploy-staging.yml — triggered by a merge to staging: builds/pushes staging-latest images, SCPs the deploy files, runs migrations, brings services up, and (re)starts Caddy.
  • deploy-production.yml — triggered by a merge to main: the same sequence with versioned images, and it also creates a GitHub Release from .release_notes/{VERSION}.md when the version is new.

Reading them for real

These are the workflows you'll interact with most; the directory may hold additional supporting workflows (release automation, housekeeping). When you need the exact, current behaviour — triggers, steps, image tags — read the files in .github/workflows/ directly, and 013 for the plugin/migration strategy they encode. When you fork, the files to update for your org and registry are called out in the deployment guide.