Admin override

Sometimes no one can satisfy a policy in time: the only member of an approver group triggered the release and self-approval is off, or the approver is away. An admin override lets an org admin release the deployment through Prodgator, on the record, instead of going around it on GitHub (which Prodgator records as a bypass).

Turn it onCopy Anchor Link

Overrides are off by default. An admin turns them on under Gates > Policies > Admin overrides:

• Allow admins to override release policies: org admins may override. Only the built-in admin role can override; a custom role cannot grant it.
• Allow the admin who triggered the release: off by default. Like self-approval, another admin has to override a release you triggered. Prodgator treats you as the person who triggered it when your linked GitHub or GitLab account started the run, or when the policy already said your approval did not count because you triggered it. While this option is off, an admin with no linked account for the deployment's provider cannot override, since Prodgator could not tell whether they triggered the release.

A gate can forbid overrides for its deployment environments: set Admin overrides to Off in the gate's approval settings (or in one deployment environment's own settings). A gate that forbids overrides wins over the organization setting. Use it for gates with strict change control, such as production.

Changing the setting writes a release_policy.override_settings_updated audit event.

Override a deploymentCopy Anchor Link

When a deployment waits on Prodgator's rule, its release policy has been evaluated and has not approved it, an admin who may override sees Override next to Approve and Reject on the pending deployment in Gates. The dialog lists the enforced policies that are not satisfied and asks for:

• a reason of 10 to 500 characters, which everyone in the organization can read
• a confirmation that this releases the deployment without the policy's approval

Override and release approves Prodgator's protection rule on GitHub or GitLab, the same answer an approval sends, with your name and reason in the comment. On a deployment environment that also has GitHub required reviewers, Prodgator submits your review too when reviewer forwarding is on, as an approval does. GitHub still decides whether your review counts.

When an admin cannot override, the pending deployment says why: overrides are off for the organization (with a link to the setting), a gate forbids them (named), you triggered the release and self-override is off, or your account is not linked.

What is recordedCopy Anchor Link

• The deployment keeps the override: who, when, the reason, whether it was their own release, the gates, and the enforced policies and rules that were not satisfied at that moment. It shows an Overridden badge with the reason on Pipelines, the Gates board, the Active and History tabs and the deployment card. The History status filter has an Overridden option.
• The audit log gets a deployment.policy_overridden entry, and the Admin Console's audit log can filter to it.
• The organization gets a critical notification, on the same channels as a bypass.
• In dashboard widgets, the Deployments source's Governance dimension counts it as overridden, apart from governed and bypassed.

Overrides are made in the app only. API keys are never admins, so the /v1 API has no override; its deployment reads include the override record.

Pull request gates have no admin override yet.