Enforce provenance without an approval

You can enforce provenance rules on most environments with no one clicking approve, and keep a person only for the environment that needs one, such as a release.

How it worksCopy Anchor Link

• An environment is protected when a gate covers it and does not exclude it. That does not depend on anyone approving, or on the provider rule being on.
• Approver groups on a gate only choose who is notified. A deployment waits for a person only when no release policy answers it.
• A release policy in Enforce mode answers the provider. It approves when all its rules pass, rejects on a blocking failure, and waits and checks again while rules are pending. It needs a person only if it has a Prodgator approvers rule.
• Observe mode records what the policy would do and never answers the provider.

Set it upCopy Anchor Link

1. Create a gate for the environments you want enforced but not approved. On Gates > Gates, click New gate, link or pattern-match the environments (for example staging and prod-*), and add no approver groups. See Set up a gate.
2. Keep the environment that needs a person in its own gate. Put your release environment in a second gate with approver groups, so only it asks for a person.
3. Create a release policy with provenance rules. On Gates > Policies, click New policy and use Releases under Used for. Add the rules you want and leave out Prodgator approvers:
   • Verified change (passes when the released change is verified with no bypass; turn on No unverified changes contained to also hold the release while earlier changes in it are unverified, and Accept expected or acknowledged bypasses to let a bypass marked expected, or acknowledged as reviewed or expected, in Provenance pass; an acknowledgement as reverted does not count)
   • Followed the declared promotion path (needs a declared promotion path in Gates > Defaults, see Promotion path)
   • Tested in an environment, unchanged
   • Coverage along the promotion path
   • Findings along the promotion path
   • Build provenance
   • Code coverage, Test results and SBOM, if you want them
4. Bind the policy. In Where policies apply, click Add binding. Use a Pattern (a repository pattern and an environment pattern such as production-*) or pick one deployment environment. See Bindings.
5. Start in Observe, then switch to Enforce. Leave Mode on Observe, check the results on a few deployments, then switch to Enforce.
6. Enable the provider rule on each environment. On GitHub, turn on the Prodgator deployment protection rule under Settings > Environments > your environment > Deployment protection rules, and remove GitHub's Required reviewers from that environment, or GitHub still asks a person. Without the Prodgator rule the environment still counts as protected for provenance and metrics, but nothing is enforced. For other providers, see Approve deployments.
7. Backfill earlier deployments (optional). Deployments from before the gate existed are not counted as protected. An admin of your Prodgator deployment can have them added; contact support to ask.

What to expectCopy Anchor Link

Enforce rejects on a blocking failure. A failing rule blocks the deployment until someone overrides it. Turn on admin override so a person with policies:override can release it on the record instead of going around Prodgator.