Merge allowed without a passing pipeline

What it is

The project does not require pipelines to succeed before a merge request can be merged.

Why it matters

CI becomes advisory. A failing pipeline is a notification rather than a gate, and broken code reaches the default branch whenever someone merges without checking.

The setting

Without the first box, the Merge button works with a failed, missing or still-running pipeline. The second box closes the [skip ci] loophole — a skipped pipeline is not a green pipeline.

The rebase gap this closes

The scenario behind the “rebase without pipeline” searches: an MR is green, the target branch moves on, the author rebases — and the rebased commits are new commits the pipeline never ran against. Without “Pipelines must succeed”, the stale green from before the rebase is enough to merge. The combination that actually holds is this setting plus merged-results pipelines (Settings → CI/CD → run pipelines against the merged result), so what gets tested is what will actually land.

What merging red actually costs

A failing pipeline someone merges past is rarely the incident itself — it is the precedent. Once red merges are normal, the pipeline stops being information: broken main becomes routine, deploys need a human to vouch for them, and the test suite decays because failures carry no consequence. The setting is less about any single merge than about keeping green meaningful.

Fix it manually

Tick both boxes. If some MRs legitimately run no pipeline — docs-only changes under rules: filters — give them a trivial always-pass job instead of leaving the gate open for everyone:

How lumioguard fixes it

The scan reads the merge-check settings alongside branch protection — the two gates only work as a pair. The fix arrives as a guide with both settings and the no-op job if your pipeline rules need it.