GitHub Actions evaluator

A pipeline gate that asks Evaluate whether this service+commit may ship. It is not the emit step. Use two steps in the same workflow — never one step that both records evidence and gates.

Package: Evitrus/actions/export@v1 with mode: check. The root evitrus/action@v1 alias also understands mode.

Setup

Mint an API key with the evaluate scope. If the gate should record deploy.blocked on deny, also grant ingest. Store it as EVITRUS_KEY.

- name: Record build evidence
  uses: Evitrus/actions/export@v1
  with:
    api-key: ${{ secrets.EVITRUS_KEY }}
    service: payments-api
    type: build.artifact.published
    image: ghcr.io/acme/payments-api@${{ steps.build.outputs.digest }}

- name: Evaluate before ship
  uses: Evitrus/actions/export@v1
  with:
    mode: check
    api-key: ${{ secrets.EVITRUS_EVAL_KEY }}
    service: payments-api
    environment: prod
    evaluate-url: https://api.evitrus.dev/compliance/evaluate

commit defaults to GITHUB_SHA. environment is sent to Evaluate so an open break-glass window for that service+environment can allow the ship. Omit it and the check step uses prod. Set staging (or similar) for non-prod gates.

wait-seconds polls Evaluate when evidence is still landing.

Failure semantics

Evaluate outcome	Step	Evidence
pass / overridden / breakglass / na	success	none extra
fail (HTTP 409)	fails the job	deploy.blocked ingested when the key has ingest
5xx / timeout / network	fail-open (step succeeds)	none — ship proceeds
Missing evidence the control needs	na — does not block	coverage gap on the Change

Pack-on includes this gate unless the tenant disables enforcement in product. Fail-open does not waive the Evaluate API SLO; it prefers a ship over a stuck pipeline.

Do not combine mode: emit and mode: check in one step. They scale, fail, and release independently even though they live in the same action repo.

See also the emit exporter.