Let your pipeline ask Milita first.
Your pipeline asks Milita to prove selected Promises. The release goes ahead only when her Proof passes.
Four steps.
Deploy to your release sandbox
Your pipeline deploys the change, just as it does today.
Ask Milita for a Proof
The pipeline starts a proof of the Promises you've selected, with a scoped API key.
Wait for the result
It checks back until Milita's run has finished.
Go ahead, or hold
If the Proof passes, the release continues. If not, it holds, and Milita shows what changed.
Available on Pro and above, where the first Proof of each Promise the pipeline starts each day is free.
Deployments are events, not causes
Milita lists your deployment as an event between the two proofs. She never says it caused a Change. Release conversations stay factual.
Inconclusive results
Your pipeline decides what an inconclusive result means. We recommend holding the release until a clean Proof passes. Exit zero only on passed; any other result, including one you have not seen before, holds the release.
A key, a Promise, a loop.
Create an API key in Settings → API keys, limited to starting proofs and reading their results. You can also limit a key to specific Promises. Keys expire after 90 days. Then your pipeline starts the Promise, polls until it finishes, and exits on the status.
set -euo pipefail
START=$(curl -sS --fail-with-body -X POST "$RA_BASE_URL/api/promises/$RA_PROMISE_ID/run" \
-H "Authorization: Bearer $RA_API_KEY" \
-H "x-idempotency-key: $CI_RUN_ID")
RUN_ID=$(printf '%s' "$START" | jq -er '.routineRunId')
DEADLINE=$(( $(date +%s) + 3600 ))
while :; do
BODY=$(curl -sS --fail-with-body "$RA_BASE_URL/api/routine-runs/$RUN_ID" \
-H "Authorization: Bearer $RA_API_KEY")
[ "$(printf '%s' "$BODY" | jq -r '.finishedAt')" != "null" ] && break
[ "$(date +%s)" -ge "$DEADLINE" ] && { echo "Proof did not finish in time" >&2; exit 1; }
sleep 5
done
STATUS=$(printf '%s' "$BODY" | jq -er '.status')
case "$STATUS" in
passed) exit 0 ;;
*) echo "Proof finished: $STATUS, holding the release" >&2; exit 1 ;;
esac
Exit zero only on passed. Any other result holds the release. The route and field names above are the ones the API serves today; we will keep this page in step with any change.
Where teams use a release gate.
Before promotion
A gate on your release or UAT sandbox before a change is promoted.
Before a go-live or a demo
A check on your most critical Promises before the moment that matters.
After a package upgrade
A re-check after a managed-package upgrade lands in a sandbox.
Put proof in your release path.
Start free, then add the release gate on Pro when your pipeline should ask Milita first.