Agent Wranglers

Recommended

Build releases only in CI and verify them before deploy

Build every release in the CI service from a reviewed commit, with signed provenance. Deploy or publish only a build whose provenance names your repository.

How to do it

A release built on a laptop can hold code nobody reviewed. Build it in the hosted CI job, and attach a signed statement of the repository, commit and workflow that made it. The SLSA framework calls this Build Level 2. Tools such as GitHub artifact attestations or Sigstore's cosign create and verify it. The deploy step verifies the statement before the switch and stops when it fails. Publish packages as publish your packages without stored tokens says. The bill of materials and release signature follow Publish what is in each release.

Examples

Using these examples: they show one way to follow this rule. Keep the behaviour and the check, not the syntax. Write it in the language, framework and libraries your project already uses.

YAML example

# GitHub Actions: sign provenance for the build. Pin the action to a full commit hash.
permissions:
  contents: read
  id-token: write
  attestations: write
steps:
  - run: npm ci && npm run build && tar -czf shop.tar.gz dist
  - uses: actions/attest@<full-commit-hash> # v4
    with:
      subject-path: shop.tar.gz

Shell example

# Deploy script: refuse anything this repository's CI did not build
gh attestation verify shop.tar.gz -R example/shop || { echo "FAIL: no valid provenance"; exit 1; }

How to check

Build a release on a laptop and try to deploy it. The deploy stops because verification fails, and the same release built in CI deploys.

Sources

For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/engineering/build-test-and-deploy/build-in-ci-and-verify">Agent Wranglers engineering playbook</a>. In code you write, add a comment next to it with the same link.