Turn policies, rules and gates off

A switch pauses something without removing it. Use it for a freeze, a noisy rule or a policy you are still tuning, when deleting or unbinding would lose work.

Where the switches areCopy Anchor Link

• Policies: the policy list, the policy editor and the policy's page each show an on and off switch.
• Rules: every form rule and custom Rego rule row in the editor has its own switch. A hand-written Rego policy has no separate rules to switch, so turn the whole policy off instead.
• Gates: the switch is on each gate's card in the gate list and on the gate's page. A gate that is off shows Disabled on the deployment board, in the environment picker and in a deployment environment's effective settings.

A policy that is off shows Disabled in lists and on deployments and pull requests. Repository policies are managed in their file, so switch them there, not in the app.

Give a reasonCopy Anchor Link

Every switch asks for a reason, from 1 to 500 characters. Without one, the change is not saved. Each change is written to the audit log with who made it and the reason:

Switching a policy or a rule also saves a new policy version that carries the reason, so the version history shows when it was turned off and on. You cannot flip a switch by editing or importing the policy definition; use the switch.

A new policy can be created or imported already turned off. That needs no reason: the policy.created audit event records that it started off. Turning it on later goes through the switch and asks for a reason.

Nothing else changesCopy Anchor Link

Turning something off keeps its bindings, versions, approvers, settings, links and exclusions. Turning it back on restores exactly what was there. Policies and gates saved before this switch existed read as on.

What a disabled policy doesCopy Anchor Link

• It is not evaluated, in either mode. Enforce and observe behave the same: a disabled policy answers nothing and is never counted.

• A policy whose rules are all disabled is treated as disabled. It never approves, and it is shown as having all rules disabled.

• A deployment or pull request whose only policies are off is treated as if no policy were bound.

• A pull request whose only policies are off gets the same answer as a pull request with no policy bound, and the check's title and summary name each policy and say it was disabled and not evaluated. Nothing is enforced. What the provider shows depends on what it supports:

  Provider	Result
  GitHub	Neutral check run
  GitLab	Successful commit status
  Bitbucket Cloud	Successful build status
  Azure Repos	Not applicable status

  On GitLab and Bitbucket the status is a success, so a merge check that requires it lets the pull request merge. Read the description to see that the policies are off.

• When some policies are off and others are on, the check lists the disabled ones next to the results of the others.

• Deployments already waiting for approval are not evaluated again when a policy or rule is switched: the next evaluation (a new approval, a re-evaluation from the deployment card or a new deployment) uses the new state, as with a binding change. Open pull requests governed by the policy are evaluated again right away.

• Deployment cards, the approval dialog, pull request results and the provenance tree list a policy that is off with its Disabled or All rules disabled badge and say it was not evaluated.

Compliance policies keep their own enabled setting and their own modes. This switch does not change them.

What a disabled gate doesCopy Anchor Link

A disabled gate stops gating: its approvers are not asked, it sends no approval notifications, and the policies attached to it do not govern deployments through it. The gate also stops marking its deployment environments as protected, unless another enabled gate covers them. That affects everything that reads protection:

• Metrics counted only for protected environments, such as the deployment-based DORA numbers and the SPACE deployment numbers, stop counting those deployments.
• Provenance checks that apply only to protected environments stop applying.

Before you turn a gate off, Prodgator shows the deployment environments that would stop being protected. Read the list before you confirm. When Prodgator could not read every deployment or repository name, the dialog says the list may be incomplete. Turning the gate back on restores protection and the gate's own settings.

Deployments already waiting at the gate are not evaluated again when it is switched; the next evaluation uses the new state.

RelatedCopy Anchor Link