Skip to content
v2.1

14. CI/CD pipeline

Rule. Every repository has the same shape of pipeline, written as GitHub Actions workflows in the repository, and nothing reaches main or a user without passing it. The full detail per stack, and where each repository stands today, is in Pipelines, versions and releases.

Why. A release is only as trustworthy as the checks in front of it. One pipeline shape across the org means a contributor who knows one repository knows them all, and a gap is visible at a glance.

The pipeline, in order. Each stage is a separate, named job so branch protection can require it.

Stage What runs When
1. Lint and format language linters, formatter check, the file-size rule (300 lines), untranslated-string guard, colour-token guard every push and pull request
2. Type check tsc --noEmit, mypy/pyright where used, Kotlin and Swift compile every push and pull request
3. Unit tests backend unit tests, frontend component tests, view-model tests on mobile every push and pull request
4. Integration tests tests against a disposable database, cache and object store started by the job (never a shared or real one) every push and pull request
5. Contract checks OpenAPI snapshot regenerated and diffed, redocly lint (org ruleset) and redocly bundle, generated client types up to date, webhook and event schemas every push and pull request
6. Guard tests the invariant guards: module registry, audit, tenancy scoping, migrations graph, docs links, design tokens and previews every push and pull request
7. End-to-end browser tests for the main flows per role, both themes, phone and desktop widths; mobile UI tests on phone and tablet pull requests into dev and main
8. Security dependency audit (blocking on high and critical), secret scan, static analysis, container image scan every pull request, and weekly on a schedule
9. Build production build of every artifact (images, web bundle, APK/AAB, iOS archive, static site) with no warnings every pull request
10. Version check VERSION raised above main, release notes file present, version strings in sync pull requests into main
11. Release only when a new VERSION reaches main: build multi-architecture images, sign them and the installer (cosign), attach an SBOM and provenance, create the vX.Y.Z tag and GitHub Release with the notes, publish latest last push to main
12. Deploy staging first, a smoke test, then production; Pages sites deploy from main after the build job after release

How to apply.

  • Pull request builds never publish anything; only main (or a manual dispatch) releases.
  • Required checks on main and dev: every stage above that applies to the stack, by job name; branches must be up to date; admins included; only the maintainer merges to main (section 12).
  • Cache dependencies per lockfile; pin actions to a version (or a SHA for third-party actions); give each workflow the least permissions it needs; secrets only in GitHub secrets or environments, never in logs or artifacts.
  • Mobile: signing keys live in GitHub environments; release builds are signed; the APK/AAB and iOS build are attached to the GitHub Release (the apps ship through GitHub Releases).
  • A red pipeline is fixed or the change is reverted; no “merge anyway”, no skipping hooks.
  • Workflow changes are reviewed like code and listed in the release notes.

Across the org. See the matrix and the gaps list in Pipelines, versions and releases. These are the rules to reach; they are not yet applied to the repositories (maintainer decision, 2026-11-13: add the rules now, change the repositories later).

Part of Space Works product rules, published from docs/product-rules.md. Edit it there.