Block deployments

Blocking deploymentsCopy Anchor Link

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.

SetupCopy Anchor Link

1. 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.
2. Optional: turn on Post the compliance status on pull requests, then in GitHub add Prodgator Compliance 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.
3. Set the policies you want enforced to Block from the mode menu on each policy's row.

Status check namesCopy Anchor Link

The compliance status is posted as Prodgator Compliance. 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 Prodgator Compliance 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 modesCopy Anchor Link

Admins set each policy's mode from its row on the Compliance page (on a narrow screen, the failure behavior is in the expanded row):

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 (production covers production in acme/api and in acme/web). 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:

deploy_frequency and mttr_threshold are organization-wide trends, so a policy made only of those can be set to Monitor or Warn, not Block.

Blocked deploymentsCopy Anchor Link

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. An admin 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-glassCopy Anchor Link

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. An 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 owner/repo 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.