Merge Gating
Merge gating posts a check on the pull/merge requests of your managed SCM repositories and decides whether they’re clear to merge. It’s configured per repository in Settings → Merge Gating.
Merge gating vs. severity gates
Section titled “Merge gating vs. severity gates”These are the two ways Vygl can stop a risky change — they work in different places:
| Merge Gating | Severity Gates | |
|---|---|---|
| Where it runs | On managed GitHub / GitLab / Bitbucket connections | In your own CI/CD pipeline |
| How it gates | A commit-status / check on the PR/MR | The CLI’s exit code |
| Set up in | Settings → Merge Gating | .vygl.yml, a CLI flag, or a project’s fail-on setting |
Merge gating applies only to managed SCM connections. If you scan through the CI/CD or local CLI paths, use severity gates instead.
Per-repository policy
Section titled “Per-repository policy”Each enabled repository has its own merge policy:
| Setting | Effect |
|---|---|
| Mode | off (no check posted), advisory (a check is posted but never blocks), or blocking (the check fails and blocks the merge). |
| Minimum severity | The lowest finding severity that counts against the PR. |
| AI verdict filter | Count all findings, or only those AI verification has confirmed as true positives. |
| Delta baseline | Gate on all open findings, or only those net-new in the PR. |
| Branches | Which target branches the policy applies to. |
A net-new baseline with blocking mode is the common choice: a PR is blocked only when it introduces a finding at or above your threshold, so existing debt doesn’t freeze every merge.
Turning on blocking
Section titled “Turning on blocking”A policy is advisory by default. Switch to blocking only after the check is wired into your SCM’s branch protection — otherwise the check posts but nothing enforces it.
- In Settings → Merge Gating, edit the repository’s policy and set the mode to blocking.
- Vygl posts a one-time seed check so the SCM registers the check by name.
- In your SCM’s branch-protection settings, add that check as a required status check on the protected branch.
- The repository’s enforcement status advances to enabled — from then on, failing checks block merges.
The Last verdict column shows the most recent check result for each repository.
Per-project overrides
Section titled “Per-project overrides”The policy is stored per repository, so different projects can gate at different thresholds — a public-facing service at high, an internal tool at critical only. There is no separate org-wide default to override; you set each repository’s policy directly.