Releases

Every repository on Airframe runs the platform’s own tooling in its pipeline: the pipeline components, the policy pack and the injected security policies; and every product starts from the platform’s product template. A release fixes exactly which version of each of those parts belongs together, under a dated name such as 2026.09.30-2. Repositories move from one release to the next on purpose, and a release found to be flawed can be revoked, which stops every new pipeline that still uses it.

Why releases exist

The platform’s tooling changes often, and a pipeline that silently picked up the newest version of every part would break in ways nobody could trace. The parts also depend on each other: the template includes the pipeline components, and the skills are tested against the policy pack. A change to one has to be checked against the others before anyone runs it.

A release solves both problems. It names one tested combination, and every repository says which combination it runs.

What a release is

A release is a small file in the control-plane repository, releases/<id>.yaml, called a manifest. It names the exact commit of each of five parts:

control-plane: the pipeline components, the policy pack and the platform’s images;
golden-path: the product template;
the modules: the Terraform modules the template uses;
security-policies: the jobs injected into every product pipeline;
platform-skills: the skills a coding agent loads.

A second file, releases/permitted.yaml, lists every release and whether it may run: permitted, or revoked with a reason and the release to move to. A manifest is never deleted, so the record of what ran stays.

How a release is made

Cutting a release is a short sequence of merge requests:

Each part is pinned to the others at the new commits, one merge request per repository. The command airframe pin <commit> rewrites the pipeline file’s includes.
One merge request in control-plane adds the manifest and its permitted line. Two jobs must pass before it can merge: release:check fetches every named commit and fails if a part pins a different commit than the release names, and the release:verify family of jobs runs each part’s own checks at those commits, such as the policy pack’s tests, the template’s three stacks, the modules’ tests and the skills’ tests.

Only a release that passed both is ever permitted.

How a repository uses a release

A repository moves to a release with airframe pin --release <id>, which rewrites its pipeline file’s includes to the release’s commits, and a merge request with nothing else in it. Going back is the same command with the previous release. Since it only changes the pipeline file, it is easy to review and easy to undo.

Revoking a release

When a review finds a flaw in a release, the fix is a merge request that changes its line in releases/permitted.yaml to revoked, with a reason and an upgrade_to.

From then on, two things refuse it:

the gate, on every new pipeline: its integrity job reads the pipeline file at the commit, checks it against the permitted list on control-plane’s main branch, and fails a pipeline pinned to a revoked release, naming the release to move to;
the executor, on every merge request run and release run, before it holds any credential.

This has already happened. Releases 2026.09.28-1, 2026.09.28-2 and 2026.09.29-1 were revoked after the reviews of 2026-09-29 found flaws in their pipeline jobs, and the permitted list names 2026.09.30-1 as the release to move to.

What a team does when its release is revoked

The failing pipeline says what to do: run airframe pin --release with the release it names, and open a merge request with that change alone. Once it merges, the repository’s pipelines run again. A commit that no release names, or a reference that moves, such as a branch, is a warning today and is planned to become a refusal in the next release.

Where it lives

In the control-plane repository: