Gates
Enforce provenance without an approval
Count deployment environments as protected and enforce provenance rules automatically, while only a release environment needs a person.
Availability
Business plan and above. Changing gates and policies needs , or a custom role with the gates and policies permissions.
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 works
- 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 up
- 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 and ), and add no approver groups. See Set up a gate.
- 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.
- 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:
- 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
- Bind the policy. In Where policies apply, click Add binding. Use a Pattern (a repository pattern and an environment pattern such as ) or pick one deployment environment. See Bindings.
- Start in Observe, then switch to Enforce. Leave Mode on Observe, check the results on a few deployments, then switch to Enforce.
- 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.
- 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.
Environment patterns
In an environment pattern, matches any characters except , and matching ignores case. A pattern also covers environments created later, for example . A broad pattern like also matches names such as . A new environment that a pattern matches is protected right away, but it is enforced only once the provider rule is enabled on it.
What to expect
Enforce rejects on a blocking failure. A failing rule blocks the deployment until someone overrides it. Turn on admin override so a person with can release it on the record instead of going around Prodgator.