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, an org admin 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.