Release policies

Who can use this: see Roles.

• Edit release policies: Release manager and Org admin.
• Override release policies: Release manager and Org admin.

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. People who can approve deployments can ask Prodgator to evaluate a deployment again.

SubjectsCopy Anchor Link

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 startCopy Anchor Link

Release policies act on Prodgator's custom deployment protection rule. For each GitHub environment you want a policy to gate:

1. Install the Prodgator GitHub App on the repository.
2. 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 decidesCopy Anchor Link

Each policy is a list of rules. Every rule returns one result:

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.

A policy, or any one of its rules, can be turned off without deleting it. A disabled policy is not evaluated in enforce or observe mode.

When policies runCopy Anchor Link

Prodgator evaluates a deployment:

• when GitHub asks Prodgator's protection rule about it,
• after someone approves or rejects it in Prodgator,
• when someone who can approve deployments 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 pending on GitHub checks or attestations, or returned error (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.

RelatedCopy Anchor Link