Skip to content

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.

These are the two ways Vygl can stop a risky change — they work in different places:

Merge GatingSeverity Gates
Where it runsOn managed GitHub / GitLab / Bitbucket connectionsIn your own CI/CD pipeline
How it gatesA commit-status / check on the PR/MRThe CLI’s exit code
Set up inSettings → 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.

Each enabled repository has its own merge policy:

SettingEffect
Modeoff (no check posted), advisory (a check is posted but never blocks), or blocking (the check fails and blocks the merge).
Minimum severityThe lowest finding severity that counts against the PR.
AI verdict filterCount all findings, or only those AI verification has confirmed as true positives.
Delta baselineGate on all open findings, or only those net-new in the PR.
BranchesWhich 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.

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.

  1. In Settings → Merge Gating, edit the repository’s policy and set the mode to blocking.
  2. Vygl posts a one-time seed check so the SCM registers the check by name.
  3. In your SCM’s branch-protection settings, add that check as a required status check on the protected branch.
  4. 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.

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.