Release policies
Decide automatically whether a GitHub deployment may go ahead, using form rules or Rego, bound to the gates and deployment environments you choose.
Availability
A release policy answers Prodgator's custom deployment protection rule on GitHub for you. When a deployment waits on that rule, Prodgator evaluates every policy bound to the deployment's repository and environment, then approves it, rejects it, or keeps it waiting.
Policies live on the Policies tab of the Gates page. and can ask Prodgator to evaluate a deployment again.
Subjects
A policy targets one or both subjects: Releases, pull requests, or both, set with Used for on the policy. Rules declare which subjects they work for, so a policy can only use rules valid for every subject it targets; saving a policy that mixes a release-only rule (such as GitHub facts) into a policy also used for pull requests is refused, naming the rule and the subject to remove. A policy used for both subjects is bound separately to deployments (below) and to pull requests, and evaluates on each independently. See Pull request gates for the pull request subject, its own bindings, its own form rules, and the input document sections it adds.
A policy created before pull request gates existed is still a release-only policy: it keeps working exactly as it did.
Before you start
Release policies act on Prodgator's custom deployment protection rule. For each GitHub environment you want a policy to gate:
- Install the Prodgator GitHub App on the repository.
- In the repository's Settings > Environments, open the environment and enable Prodgator under Deployment protection rules.
Without the rule, GitHub never asks Prodgator about the deployment and no policy runs. GitHub runs custom deployment protection rules only on public repositories, or on private repositories on GitHub Enterprise.
How a policy decides
Each policy is a list of rules. Every rule returns one result:
| Status | Meaning |
|---|---|
| The rule is satisfied. | |
| The rule is not satisfied. | |
| The rule is waiting for something, such as an approval or a running check. | |
| The rule could not be evaluated. |
A rule is either blocking or not. The policy's decision follows from its results:
- Reject when any blocking rule fails.
- Approve when every rule passes.
- Wait otherwise. A failed rule that is not blocking holds the deployment without rejecting it.
A policy runs in one of two modes:
- Enforce: the decision counts. Prodgator answers GitHub when the enforce policies agree.
- Observe: Prodgator records the decision on the deployment but never answers GitHub. Use it to try a policy on real deployments before you enforce it.
When several policies are bound to the same deployment, Prodgator rejects if any enforce policy rejects and approves only when every enforce policy approves. Observe policies never change the answer.
When Prodgator answers, it posts a comment on the GitHub deployment that names the policies, their versions and each rule's result.
When policies run
Prodgator evaluates a deployment:
- when GitHub asks Prodgator's protection rule about it,
- after someone approves or rejects it in Prodgator,
- when an editor or admin clicks Re-evaluate on the deployment,
- when any workflow run on the deployment's commit (same repository and SHA) sends an attestation with the Prodgator report action,
- on a schedule while a rule is on GitHub checks or attestations, or returned (up to 8 re-checks, spaced further apart each time, over about an hour).
Each evaluation is stored with the deployment. Open the deployment to see its evaluation history and the result of every rule.
Related
Form rules
Approvers, GitHub facts and attestations without code.
Write a policy in Rego
The result contract, tests and what Rego can use.
Release input document
Every field a rule can read for a deployment.
Bindings and approver groups
Which deployments a policy governs, and who can approve.
Test, import and store policies
The playground, .rego files and policies kept in a repository.
Admin override
Release a deployment the policy has not approved, with a reason.
Security, audit and limits
Who can change policies, the audit trail and the limits.
Roll back a deployment
Re-run the newest earlier successful deployment to the same deployment environment, and what Prodgator exposes to automation.
Form rules
Rules you set up in a form, without Rego: Prodgator approvers, GitHub facts, attestations, required checks, change size, required reusable workflows, allowed actors and AI-assisted changes.