Deployment gates

Gate the merge with a required check

Enable the merge gate for a repository and choose its blocking severity. Then add Proofline gate as a required status check in your GitHub branch protection or ruleset.

The gate blocks a pull request head if its assessment is incomplete or production evidence is missing. It also blocks when an open supported finding meets the severity you chose. See how to set up a merge gate.

Gate the deployment itself

A deployment gate checks the change at the delivery step. It works with GitHub Actions deployment protection rules and with Cloud Build triggers that require approval.

New deployment gates fail closed: an incomplete review or missing evidence holds the deployment just as a blocking finding does.

If Slack is connected, a blocked GitHub Actions or Cloud Build deployment posts a message with approve and reject actions. The audit log records every decision made there. The deployment protection guide has the setup steps.

A policy you can audit

Each pull request head keeps the policy captured when its review started. Changing the policy later affects new heads only, and earlier decisions stand.

The gate history lists every recorded head and decision, including any GitHub merge that bypassed a blocked gate.

Gates are opt-in. Without a gate, the Proofline check stays neutral and your team decides from the findings.

Questions

Does a deployment gate pass when evidence is missing?

No. New deployment gates fail closed, so an incomplete review or missing evidence holds the deployment.

Which delivery systems can Proofline gate?

Proofline can gate GitHub Actions deployments, through deployment protection rules, and Cloud Build triggers that require approval. Pull requests use the Proofline gate required check.

Can I override a blocked Proofline gate?

Yes. If Slack is connected, a person can approve a blocked GitHub Actions or Cloud Build deployment from Slack, and the audit log records it. The gate history also records a merge that bypassed a blocked gate.