CI/CD integration
Run the simulator in your pipeline, sign with temporary keys in a temporary partition, and let everything disappear when the run ends. The simulator enforces the same policies as the appliance, so a test that passes here passes in production.
Pipeline
# GitHub Actions
services:
roost:
image: ghcr.io/axowl/roost-sim:1
ports: ["8080:8080"]
steps:
- run: roost partition create ci-$GITHUB_RUN_ID --ttl 30m
- run: roost key create --purpose code-signing --name ci-$GITHUB_RUN_ID-sign --partition ci-$GITHUB_RUN_ID
- run: ./build && roost sign ci-$GITHUB_RUN_ID-sign dist/app.bin
- run: roost verify ci-$GITHUB_RUN_ID-sign dist/app.bin dist/app.sig
# purge: the partition expires on its ownTest data lifecycle
| Step | What happens | Who does it |
|---|---|---|
| Provision | A partition for this run, with a lifetime | One command |
| Fixtures | Keys named after the run, for example ci-build-842-sign | One command per key |
| Execute | Tests sign, verify, wrap and unwrap | Your tests |
| Validate | Receipts and envelopes are checked | Your tests |
| Purge | Partition and keys expire | Roost, automatically |
Release signing with approval
The release job sends the artifact hash with the approval it received from the approvals inbox. Without it, the production key refuses with a reason, and the refusal is on record. Rules can run in record-only mode during a rollout. See Approvals and policies.
AxowlacmeRoostM
CI/CD
2runs active
184runs this week
0keys left behind
| Run | Partition | Keys | Started | Expires | Result |
|---|---|---|---|---|---|
| build-843 | ci-build-843 | ci-build-843-sign | 09:31 | 10:01 | Running |
| build-842 | ci-build-842 | ci-build-842-sign | 09:12 | 09:42 | Passed · released |
| build-841 | ci-build-841 | ci-build-841-sign | 08:50 | expired | Refused · no approval |
Simulator: ghcr.io/axowl/roost-sim:1 · same policy code as ROOST-26-0001 (1.1.0)