Bindings and approver groups
Choose which deployments a release policy governs, and keep the list of people who may approve in one place.
Availability
Bindings
A policy does nothing until it is bound. A binding says which deployments the policy governs:
- One deployment environment: one repository and environment, for example and , optionally narrowed to one workflow by its file (for example , or ). This is the default for a new binding. A binding in a repository policy file that names means the same file.
- Pattern: a repository pattern and an environment pattern, for example and . matches any characters except , also matches , and matches one character. Matching ignores case. A pattern also covers repositories and environments added later; with covers every environment named in every repository.
- Gate: attach a policy to a gate (formerly called an environment) to govern every deployment to the deployment environments it links.
Each field lists the repositories, environments, workflows and branches Prodgator has seen, filtered by the repository you chose. You can also type a value, such as a pattern or a repository that has not deployed yet.
Environment names are not unique: in and in are different deployment environments. Bind one deployment environment, or a gate that links the ones you mean, unless you want a name to apply everywhere.
These three kinds govern deployments and need the policy's Used for to include Releases. A policy used for pull requests instead (or as well) takes a fourth kind, a pull request binding (a repository pattern and a base branch pattern); see Pull request gates. A pull request binding never governs a deployment, and a release binding never governs a pull request.
Add and remove bindings in the Bindings panel on the Policies page. A policy that is still bound cannot be archived; remove its bindings first.
Approver groups
An approver group is a named list of organization members, for example "Release managers". Use groups in the Prodgator approvers rule so you can change who may approve without editing every policy.
Manage groups in the Approver groups panel on the Policies page. A group has 1 to 200 members, and an organization can have up to 50 groups. A group that a policy uses cannot be deleted.
When a rule does not allow self-approval, give its groups at least two members. A group's only member can never approve a deployment they started, so that deployment waits until someone else approves it (see When an approval does not count).