Approve deployments

Answer deployments on the Gates page's Awaiting approval tab, on a gate's own page, or from the Pipelines list.

Two kinds of gateCopy Anchor Link

A GitHub environment can hold a deployment for two reasons. Prodgator shows which one is open.

• Prodgator's protection rule: the Prodgator GitHub App, turned on as a deployment protection rule on the environment. Only Prodgator can answer it.
• Required reviewers: the environment's required reviewers in GitHub. Prodgator submits your review with your own linked GitHub account.

When an environment has both, you answer Prodgator's rule first. The deployment stays pending until the required reviewers answer too.

Prodgator's protection ruleCopy Anchor Link

Turn it on in GitHub under Settings > Environments > your environment > Deployment protection rules. GitHub then asks Prodgator before each deployment to that environment.

Prodgator answers a request automatically only when a policy evaluates the deployment:

• A compliance policy in Block mode covers the environment, on a plan with blocking enforcement (Enterprise). Prodgator approves when every Block policy passes and rejects when one fails, unless a break-glass override is active. If a Block policy waits on other CI runs for the same commit, the request stays pending for up to the Wait for CI time.
• A release policy in enforce mode is bound to the environment. Prodgator answers from your release policies and compliance policies together. See Approvals under a release policy.

Otherwise Prodgator does not answer. The deployment shows Awaiting approval in Prodgator on the Gates and Pipelines pages until someone approves or rejects it there. This includes plans without blocking enforcement, environments no Block policy covers, and the rare case where Prodgator cannot read your policies. Prodgator never approves a deployment because no policy applies.

While a request is still pending you can answer it by hand:

• If no Block policy governs the environment, an editor or admin can approve or reject. A note is optional. The answer is written to the audit log and the comment on GitHub names who approved.
• If a Block policy governs it, answering by hand overrides Prodgator's decision. Only an admin can do it, and must give a reason of 10 to 500 characters. The override is written to the audit log.

A workflow can wait up to 30 days on environment approvals. After that GitHub stops waiting and the job does not deploy, so answer pending deployments before then. Prodgator moves a deployment still pending after 30 days out of Awaiting approval as cancelled. See GitHub Actions limits.

GitHub runs custom deployment protection rules only on public repositories, or on private repositories on GitHub Enterprise.

A GitHub admin can start a deployment without waiting for the rule. Prodgator marks it Bypassed. See Bypassed deployments. To release a deployment its release policy has not approved without going around Prodgator, an org admin can use an admin override.

Required reviewersCopy Anchor Link

GitHub records whoever submits a required-reviewer review as the reviewer, so Prodgator submits it with your own GitHub account, never the organization's connection.

1. Link your GitHub account under Profile > Linked accounts. See Linked provider accounts.
2. Approve or reject in Prodgator. Your review goes to GitHub as your account.

If your account is not one of the environment's required reviewers, Prodgator says so and offers Review on GitHub. If your link has expired, it offers Link GitHub again.

GitLabCopy Anchor Link

GitLab protected environment approvals work the same way as required reviewers, with a linked GitLab account. GitLab records the approver as the person whose token made the call, so link your own GitLab account first (see Linked provider accounts).

BitbucketCopy Anchor Link

Bitbucket Cloud has no API to approve, resume or run a paused deployment step, so Prodgator cannot release a Bitbucket deployment from outside the pipeline. Instead, the deployment step asks Prodgator: the Prodgator pipe runs first in the step with GATE: 'true' and waits.

The gate is Prodgator's protection rule, so it works like the GitHub rule above:

• An editor or admin approves or rejects it in Prodgator, a note optional. No linked Bitbucket account is needed: nothing is sent to Bitbucket, and the step reads the decision.
• A release policy in enforce mode bound to the environment answers it automatically, and a Block compliance policy on the environment needs an admin and a reason to override, as on GitHub.
• API keys with write:deployments can answer it, with a reason.

Approved, the pipe exits 0 and the step deploys. Rejected, the pipe exits 1 and the step stops; the pipeline log shows who rejected it and the note. A step that ends with the gate still open is recorded as Bypassed if it deployed anyway (for example, the pipe was removed or its exit code ignored).

Deployment steps without the gate (a trigger: manual step, or one held by Bitbucket's deployment permissions) are still run in Bitbucket.

Azure DevOpsCopy Anchor Link

An Azure DevOps environment can hold a deployment for two reasons, and Prodgator shows which.

• Azure DevOps' own approvals and checks. Prodgator shows who must approve, the status and an Approve in Azure DevOps link. It has no Approve or Reject button for these: Azure DevOps records the decision, and the result shows in Prodgator. Prodgator never approves, rejects or forwards one. Linking your Azure DevOps account (see Linked provider accounts) lets Prodgator show you by name as the approver.
• The Prodgator gate. A check you add to the environment from Gates > Protect an Azure DevOps environment. See the Prodgator gate. It works like the GitHub protection rule above:
  • An editor or admin approves or rejects it in Prodgator, a note optional. No linked Azure DevOps account is needed: Azure DevOps asks Prodgator, and Prodgator answers the check.
  • A release policy in enforce mode bound to the environment answers it automatically, and a Block compliance policy needs an admin and a reason to override, as on GitHub.
  • API keys with write:deployments can answer it, with a reason.

Approved, the stage continues. Rejected, the stage fails; who rejected it and why is in Prodgator's audit log. A gate left open expires after 47 hours and the stage fails. If an environment has both kinds, Azure DevOps runs both and the stage starts when all have passed.

Jenkins deployments cannot be approved from Prodgator.

Approvals under a release policyCopy Anchor Link

When an enforce release policy governs a deployment, approving or rejecting Prodgator's protection rule from the deployment card does not answer GitHub directly. Prodgator records the approval, which the Prodgator approvers rule can count, and evaluates the policies again. API keys cannot approve a governed deployment.

Bulk approve and rejectCopy Anchor Link

On Awaiting approval (or a gate's own pending approvals):

1. Tick the releases you want to decide, or use Select all pending my approval to select every release waiting on you in the current scope.
2. Click Approve or Reject in the selection bar. You can select up to 50 at a time.
3. A confirmation lists every selected release (repository, workflow, deployment environment, run and version). Nothing is sent until you confirm.
4. To reject, give a reason of 10 to 500 characters and type reject to confirm. The reason is sent to the provider as the comment on every rejected release.

Each release is decided on its own, with the same checks, policies and audit entry as a single approval. The results list each release. A release that needs a compliance override reason from an admin, or your linked GitHub account, is not decided in bulk: it shows Open, which takes you to its own approval dialog. A large selection can run out of time; releases not reached show "Not decided. Select it again."

What Prodgator posts to the providerCopy Anchor Link

Bitbucket takes no comment: there, who answered and the note appear in the step's log and in Prodgator's audit log. On Azure DevOps, the check's answer carries only approved or rejected, so who answered and the note are in Prodgator's audit log.

On GitHub and GitLab, each approval or rejection posts a comment on the provider that names who answered: display name, email, Prodgator user ID and organization, followed by your note. An admin override starts with "Manual override of a Prodgator compliance decision" and the reason. An answer made with an API key names the key instead.

API keys with the write:deployments scope can answer Prodgator's protection rule, always with a reason. They cannot answer required-reviewer gates. See the Public REST API.

NotificationsCopy Anchor Link

Approval requests and their results create notifications in the bell. A request opens its approval on Awaiting approval; a result opens History. They can also go to Slack or an outbound webhook under the Deployments category. See Notifications.