Block deployments
Let compliance policies approve or reject GitHub deployments, choose each policy's mode, and let a blocked deployment through with break-glass.
Availability
Who can use this: see Roles.
- Manage compliance policies: Compliance and Org admin.
- Create break-glass overrides: Compliance and Org admin.
Blocking deployments
On the Enterprise plan the Deployment enforcement section lets policies act on GitHub deployments. It has three tabs, and each policy's mode, failure behavior and environments are set on the policy's own row above it.
Setup
- In GitHub, open the repository, then Settings > Environments > your environment > Deployment protection rules, and enable the Prodgator rule. GitHub allows at most 6 deployment protection rules per environment.
- Optional: turn on Post the compliance status on pull requests, then in GitHub add as a required status check in branch protection or a ruleset. This blocks merges that fail a Block policy. The Setup tab can download a ready-made ruleset that requires the status on a repository's default branch, or show the same ruleset as code.
- Set the policies you want enforced to Block from the mode menu on each policy's row.
Status check names
The compliance status is posted as . Use that name when you add it as a required status check.
With Post the compliance status on pull requests on, the Pull requests page shows a small Compliance chip next to the gate for a pull request with a posted status, and the Prodgator Policies check run's summary adds one line naming the same state and reason. This only mirrors the status; it changes nothing about that status itself.
Wait for CI (5 to 120 minutes, default 30) sets how long a deployment waits for other CI runs on the same commit before a "CI must pass" policy fails it.
GitHub runs custom deployment protection rules only on public repositories, or private repositories on GitHub Enterprise. If no protection rule request has reached Prodgator yet, the Setup tab says so and suggests status-check mode, which gates merges instead of deployments.
Policy modes
People who manage compliance policies set each policy's mode from its row on the Compliance page (on a narrow screen, the failure behavior is in the expanded row):
| Mode | Effect on a deployment |
|---|---|
| Monitor | Evaluated and recorded. Never affects the deployment |
| Warn | A failure is listed in the comment Prodgator posts when a Block policy also covers the environment. Warn alone does not answer the deployment |
| Block | A failure rejects the deployment |
Prodgator answers its protection rule automatically only when a Block policy covers the environment. With only Monitor or Warn policies, or none, the deployment waits for someone to approve or reject it in Prodgator. See Approve deployments.
For a Block policy you also choose what happens if evaluation itself fails: Fail closed (reject, the default) or Fail open (approve). You can limit a policy to environment names; a name applies in every repository and workflow ( covers in and in ). Pick names from the list or type new ones, and leave the field empty for all environments. To govern one deployment environment only, use a release policy bound to it.
Only rules that can judge a single deployment can block:
| Check | Per deployment |
|---|---|
| Every other CI run for the deployed commit must succeed. Still-running runs are waited for, up to Wait for CI | |
| No open Critical alerts in the repository | |
| No open secret scanning alerts in the repository | |
| No open vulnerability in the repository on the CISA KEV list. If the vulnerability data cannot be read, the deployment waits, and when Wait for CI expires Fail closed rejects and Fail open approves. A pull request status decides at once | |
| No contained open unverified changes, excluding expected or acknowledged changes | |
| At least one upstream environment, all with unchanged code | |
| Repository or organization promotion path followed in order | |
| Lowest trusted line coverage along the path meets a threshold from 0 to 100 | |
| A trusted scan and no findings at or above severity rank 4 critical, 3 high, 2 medium or 1 low |
The five provenance checks apply only to protected deployment environments and need release provenance in the plan. They wait while evidence is pending. Incomplete or truncated lineage, an unreadable promotion step or a release off the declared path fails even under Fail open. A read error passes under Fail open. After Wait for CI expires, Fail open allows a policy through only if all its pending checks are waiting for lineage collection itself. A pending promotion step or a deployment whose ID has not arrived fails at that deadline. See Verified changes and promotion checks for API setup and other error outcomes.
and are organization-wide trends, so a policy made only of those can be set to Monitor or Warn, not Block.
Blocked deployments
Lists each decision Prodgator made on a deployment: approved, blocked, still evaluating, not delivered to GitHub, or awaiting approval in Prodgator (no Block policy covered the environment, so Prodgator did not answer). Blocked only narrows the list. Compliance and Org admins can click Re-send on a decision that is still evaluating, failed to reach GitHub, or is waiting for approval in Prodgator; Prodgator then evaluates it again, which answers it if a Block policy now covers the environment.
Break-glass
A break-glass override lets blocked deployments to one repository and environment through for a limited time: 15 minutes, 1 hour, 4 hours or 24 hours. Someone with the break-glass permission (Compliance or an Org admin) creates it with the repository, the environment and a reason of 10 to 500 characters. Pick the repository from the list or type its name; the environment list then shows that repository's environments, and you can type a name it has not deployed to yet. Every use is written to the audit log and to the comment Prodgator posts on GitHub.