Bypassed deployments
How Prodgator marks a deployment that went out without waiting for its gate, and where you see it.
A GitHub admin can start a deployment without waiting for the environment's protection rules, and a GitLab or Bitbucket deployment can be run on the provider while its gate still waits. When a deployment goes ahead while Prodgator's rule is still pending, or after Prodgator rejected it, Prodgator marks it Bypassed instead of approved.
Bypassed deployments
- The deployment leaves Awaiting approval and shows a Bypassed badge on Pipelines, on the Gates board and on the Active and History tabs. The History status filter has a Bypassed option.
- The deployment names who released it, when the provider says, the gates that contain the environment, and the policies it was still waiting on:
- GitHub: who the run's review history lists as approving it.
- GitLab: who ran the deploy job, else who approved the deployment in GitLab.
- Bitbucket: who started the pipeline. Bitbucket does not say who started a manual step.
- The organization gets a critical notification, and the audit log gets a entry.
- In dashboard widgets, the Deployments source's Governance dimension counts it as , apart from deployments.
Prodgator waits a few seconds before calling a deployment bypassed, so its own approval that was on its way to GitHub is never counted as a bypass.
To release a deployment whose release policy cannot be satisfied without going around Prodgator, someone who can override release policies (Release managers and Org admins, once an Org admin allows overrides) can override the policy in Prodgator instead, with a reason. See Admin override.
Pull requests merged past the Prodgator check are marked in a similar way. See Merged with bypass.