The release gate is a single read-only endpoint. Your pipeline calls it with an API key and the system's ID, and the response tells the job whether to continue.
Exit codes
- PASS — exit code 0. All mandatory controls are satisfied.
- REVIEW — exit code 2. Non-blocking warnings or approvals still pending.
- BLOCKED — exit code 1. Missing evidence, failed evaluations, an open contract breach, or missing approvals. Also returned when the decision cannot be read, so the gate fails closed.
The workflow step
- name: Check Assurance OS release gate
env:
API_KEY: ${{ secrets.ASSURANCE_API_KEY }}
SYSTEM_ID: ${{ vars.ASSURANCE_SYSTEM_ID }}
run: |
res=$(curl -fsS -H "X-Api-Key: $API_KEY" \
"https://<your-host>/api/v1/ci/release-gate?systemId=$SYSTEM_ID")
echo "$res" | jq -r .content
exit "$(echo "$res" | jq -r .exitCode)"Deciding what REVIEW means for you
Any non-zero exit fails a GitHub Actions job. If you want REVIEW to warn rather than stop the deploy, map exit code 2 to success in a wrapper step and post the blockers to the pull request instead. BLOCKED should always stop the job.
Keep keys scoped
Create a dedicated API key for CI from Settings. A key acts with the permissions of the user who created it and cannot create or revoke other keys, so a leaked CI key cannot mint replacements. Store it as an encrypted repository secret.
This article is general information, not legal advice. Your counsel decides how the law applies to your systems.
