Renovate auto-merges before CI finishes: three failing builds landed on main

[jimisola]

What happened

Renovate's auto-merged PRs are landing on main before their checks finish, and failing builds have already gone in.

reqstool/reqstool-client, three consecutive PRs:

PR	merged at	build completed	build result
#450	00:01:35	00:02:54	failure
#449	01:03:56	01:05:01	failure
#448	01:03:51	01:04:57	failure

#450 was merged four seconds after renovate-approve[bot] approved it — while build still had 79 seconds to run. The merge did not race CI; it never waited for it.

Why

Three settings that are individually defensible and collectively remove every gate:

1. protect-main requires no status checks. rules on the live ruleset are deletion, non_fast_forward, pull_request, required_linear_history — there is no required_status_checks rule, in safe-settings/suborgs/all.yml or anywhere else.
2. Renovate holds a ruleset bypass — actor_id: 2740, actor_type: Integration, bypass_mode: pull_request — so the pull_request rule does not apply to its PRs either.
3. platformAutomerge: true in the shared preset, with automerge: true on minor and patch.

GitHub's auto-merge waits for required checks and required reviews. With no checks required and the review bypassed, "mergeable" is true the moment the PR opens, so it merges immediately. build is not required, so nothing waits for it.

Fix

Two changes, in order of how much they buy:

• platformAutomerge: false (reqstool/.github#TBD). Renovate then merges the PR itself on its next run, and its own automerge waits for the branch to be green outright — every check, not just the required subset. This is the change that stops the bleeding, and it does not depend on any per-repo knowledge of check names.
• Drop Renovate's ruleset bypass (reqstool/.github-private#TBD). It is no longer needed: renovate-approve[bot] supplies the approving review the pull_request rule wants — it did so on #450. Keeping the bypass means that any check made required in future silently would not apply to Renovate's PRs, which is the same failure again with more steps.

Not fixed here

protect-main still requires no status checks, so a human PR can also be merged red. Fixing that properly means per-repo required contexts — build in reqstool-client is not the context name in every repo — which is safe-settings/repos/<repo>.yml work, one file per repo, and each context must have run on a real PR before it is required or it blocks every PR on that repo. Worth a separate issue.

Also

reqstool-client's main has taken three failing builds. Worth checking whether it is currently green before anything else is cut from it.

Compare: skillsgateway reached the same conclusion from the other direction — it requires seven checks and gives Renovate no bypass, and its preset uses platformAutomerge: false for exactly the reason above.

[jimisola]

Both fixes are up: #112 (preset) and https://github.com/reqstool/.github-private/pull/34 (ruleset bypass). Merge the preset first — it is the one that stops failing builds landing.

[jimisola]

Both fixes verified against the live API, not the PR text.

#112 (preset) — platformAutomerge: false is on origin/main of .github/renovate.json5.

#34 (ruleset bypass) — protect-main on reqstool-client now lists exactly one bypass actor:

bypass_actors: [ { actor_type: OrganizationAdmin, actor_id: null, bypass_mode: always } ]
rules:         deletion, non_fast_forward, pull_request, required_linear_history

Integration 2740 is gone.

Live proof the fix works

Renovate PR reqstool/reqstool-client#451 (mcp → 2.1.1) is sitting open and unmerged:

• autoMergeRequest: None — GitHub auto-merge is no longer being requested
• reviewDecision: APPROVED — renovate-approve[bot] still supplies the review, so dropping the bypass did not strand it, exactly as chore(ci): add reusable Renovate config validation workflow #34 predicted
• build: FAILURE — and Renovate is holding the merge because the branch is not green

Its three predecessors merged in 4–28 seconds with red builds. This is the intended behaviour, observed rather than assumed.

The incident was wider than recorded here: 5 PRs across 3 repos

Applying the same merged-at vs check-completed comparison to the other repos surfaces two more from the same night:

repo	PR	merged	build completed	result
reqstool-java-annotations	#183	02:15:12	(pypi) 02:15:44 · (main) 02:15:54	failure
reqstool-python-decorators	#96	01:47:32	(pypi) 01:48:44 · (main) 01:48:39	failure

Both of those main branches recovered on their own and are green now. The pattern was org-wide rather than a reqstool-client quirk, which strengthens the case in Not fixed here.

The "Also" note was right — main was still red

reqstool-client's main HEAD is #450's merge commit, and its build failed. Not a flake.

#450 bumped mcp 2.0.0 → 2.1.0, which narrowed which exceptions reach the client. Per the SDK's own docstring, only a ToolError keeps its message; everything else is treated as a crash and reported as a bare Error executing tool <name>. The MCP server raised ValueError/RuntimeError for failures it fully anticipated, so all of them were masked — an agent asking for a mistyped REQ_TYPO got Error executing tool get_requirement and no way to see the typo.

One test caught it. Reverting only the source change fails 8, spanning get_requirement, get_svc, get_mvr, get_requirement_status and get_status — the other seven asserted is_error without asserting the reason survives.

Fix: reqstool/reqstool-client#452, green. main goes green when it lands.

Still open

protect-main requires no status checks on any repo checked (reqstool-client, -vscode, -java-annotations, -python-decorators, -docs all carry the identical four rules), so a human PR can still be merged red. The build context name genuinely differs per repo — build, build / build, build (main) + build (pypi), and reqstool-docs has none — so it is per-repo safe-settings/repos/<repo>.yml work, as this issue already noted.

[jimisola]

main is green again.

reqstool/reqstool-client#452 is merged, and both workflows on 2c4739b pass:

2026-08-29T20:34:17Z  success  2c4739ba  Build PyPI
2026-08-29T20:34:16Z  success  2c4739ba  Push on main

The three failing builds this issue opened on are cleared.

The fix demonstrating itself

#451 (mcp → 2.1.1) is the neatest confirmation of both changes working together. It was opened on 2026-08-28 at 20:12 and sat unmerged for a day with a red build — where its three predecessors merged in 4–28 seconds. When #452 landed, Renovate rebased it automatically onto the new main, so it now carries the ToolError fix and the 2.1.1 bump together and can go green on its own.

Under the old settings it would have merged on 2026-08-28 at 20:12 with a broken build — a fourth failure on main. It did not, because platformAutomerge: false means Renovate waits for the branch to be green outright, and it still gets its approving review from renovate-approve[bot] with no ruleset bypass.

Closing: both fixes are merged, verified against the live API, and observed working on a real PR.

Follow-up for required status checks tracked separately — protect-main requires none on any repo checked, so a human PR can still be merged red.