Gates defaults
Set fallback promotion paths and review gate defaults.
Open Gates > Defaults for organization defaults. See approval settings for approval controls and bypassed protection for expected bypasses and automatic close on revert.
Declared promotion path
Business plan and above. Everyone can read paths; editing needs (Release managers and Org admins by default).
Set an organization path or a path for a repository. Each has 1 to 6 ordered branch steps with an optional deployment environment per branch. Every step names a branch; a one-step path, such as just , suits a trunk-based repository. An environment accepts wildcards ( matches any characters except , matches any characters including ; see Promotion path). The repository path replaces the organization path for that repository. Repository identity includes the provider and immutable repository ID, so renaming it keeps the setting.
A release policy can carry its own path, including environment or gate steps. That path takes precedence for its rule. The repository and organization paths are the fallback when the rule has no path. With none, an enforced declared-path rule holds the gate. Compliance's check uses only the repository and organization paths.
The path sets the expected order. It does not change how Prodgator discovers the code's history. Each required branch deployment is checked against the promoted merge commit, and skipped or out-of-order steps are shown. See Promotion path.
Tag releases
If you release from tags, set the organization or repository path with the trunk branch, for example alone. Every Defaults step names a branch, and a tag release is matched at the step of the branch where its tagged commit landed. Later steps are not checked for a tag release, and the environment on the landing step is not enforced there: the release step checks only that the landing change is a verified pull request. A Defaults path such as , then , then therefore does not require a or deployment for a tag release. To require "main, then staging, then production", use a release policy with its own path that has a branch step followed by environment or gate steps. There is no separate tag or release step: a branch step is met by the branch itself, by a tag created from a commit on that branch, and by a release created from that tag, when the tagged commit landed on that branch through a verified change. Prodgator asks the provider whether the deployment ref is a tag. For a tag, the repository and organization paths match the release by the branch where the tagged commit landed, not by the tag name.
The change that landed the commit meets its branch step only when it is a verified pull request, including when that branch is the release step. A direct push fails the step, a commit that never landed on that branch through a change does not pass, and a ref the provider cannot classify, or a tag that no longer points at the deployed commit, stays "could not be checked". A branch step also needs a successful deployment of the landed commit from that branch (the environment is optional), otherwise the step is missing. This does not apply when the landing branch is the release step itself, such as a one-step path: that step checks only the landing change. See tag releases on a trunk-based path, which also shows a rule that requires the released change to be verified.
Approval settings
Self-approval and reviewer forwarding for your organization, a gate or one deployment environment, and which one applies.
Approve deployments
The two kinds of gate on a GitHub environment, GitLab, Bitbucket and Azure DevOps approvals, approving and rejecting from Prodgator one at a time or in bulk, and what Prodgator posts to the provider.