New config option: requireTestsForAutomerge to prevent race condition automerges

[adelaon]

Tell us more.

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitHub, GitLab, 41.9.0

Problem

Currently, Renovate may automerge PRs before CI tests have started running, creating a race condition:

1. Renovate creates a PR
2. Renovate checks branch status immediately
3. No CI checks have registered yet (CI is still queuing/starting - this may take around 30 s)
4. Renovate automerges (because no failing checks exist)
5. CI starts and runs tests after the merge completes

This defeats the purpose of having CI configured on the repository. While the repository has automated testing set up, the race condition allows merges to bypass it entirely.

Why Not Use Platform Branch Protection?

Setting up a "Require a successful pipeline for merge" (GitLab) or "Require status checks to pass" (GitHub) does not solve this issue, because:

• These settings apply to ALL merges (manual and automated)
• They block merges even when tests are intentionally skipped or not applicable
• Repository owners may want more flexibility for manual merges
• Renovate should be able to enforce its own stricter requirements for automated merges

This new config option would allow Renovate-specific control: automated PRs wait for CI, while manual merges remain flexible.

Proposed Solution

Add a new configuration option requireTestsForAutomerge (boolean, default false) that blocks automerge until at least one CI test-related status check is present on the branch.

Configuration Example

{
  "automerge": true,
  "requireTestsForAutomerge": true
}

Behavior

When enabled:

• Renovate checks for the presence of CI status checks before allowing automerge
• Filters out non-test checks (deployments, coverage reports, security scans, etc.)
• Blocks automerge if no test-related checks are found
• Works with both PR and branch automerge strategies
• Respects ignoreTests setting (check is skipped if ignoreTests: true)

I can open a PR if you agree on this approach.

[jamietanna]

Are you using ignoreTests? Because without this set, that should be the default behaviour 🤔

[adelaon]

No, ignoreTests is false

Well, if I want platformAutomerge to be set to true (so the default value), then the CI status checks are left to the platform and not Renovate. Sometimes the CI pipelines take a while to appear and before they do, the platform (GitLab in this case) merges the MR, because it does not see a running or failed state.

Which is why I would like Renovate to have a config option, which would make it Renovate responsibility to check if there are any CI statuses (so basically that the CI pipelines started) and only then set automerge to true.

[micheljung]

We're facing a similar issue, but with Platform Branch Protection enabled, which gets "canceled out" by the stability days check (see #39923).

I see one downside in your suggested solution: Renovate would only set automerge next time it runs.

This could be improved by letting renovate initialize the status check if it's missing. I imagine something like this:

{
  "requiredStatusChecks": [
    {
      "name": "ci-build",
      "createIfMissing": true
    }
  ]
}

Then, when renovate creates the MR, it could create the status check ci-build in a pending state. This state would then prevent the Platform (e.g. GitLab) from auto merging when branch protection is enabled (my case). In your case, even with createIfMissing: false, Renovate would not auto merge as long as ci-build doesn't exist and is successful.

What do you think @adelaon @jamietanna ?

[adelaon]

Hello, yes, that is a downside, which for our case specifically is acceptable, but I understand it might not work for everyone.
Could you elaborate more about your suggested solution? How would creating the check work? And when would it move from pending to passed?

[micheljung]

Hi,

How would creating the check work?

I'm not sure what you're asking. A status check is simply a name and a state (pending/passed/failed). So Renovate would just create that when it creates the MR - just like it creates the stability days status check. And it would do so before setting auto merge.

And when would it move from pending to passed?

That would be done by the CI Job.

The root issue is that the CI Job creates the status check too late. This could be solved by letting Renovate creating it. After that, the CI will continue updating the status check.

This only works if it's possible for one system to modify the status check of another system. I'm not sure if that's the case.

[jamietanna]

Might also be related: #27111

[adelaon]

Isn't this issue talking about when renovate is responsible for the automerge? My case is more about when the platformAutomerge is enabled, which has different workflow then the renovate automerge.

[adelaon]

Hi, it has been some time and I would like to get some attention here again.

Let me try to explain the problem/purposed solution more clearly. In the beginning, I was talking about multiple platforms, but this actually applies only to GitLab AND it applies only when platformAutomerge=true.

Problem:
Here is a for loop checking if the merge request can be merged and has a pipeline. However, after some number of checks (5 default), Renovate always allows automerge on the MR (even if no CI checks were found).

My purposed solution:
Create new config option, like it is said in the initial message (requireTestsForPlatformAutomerge). Then create a helper variable testsPresent just before the loop begins. When the loop breaks early, set testsPresent = true;. And finally, before attempting to set automerge on the MR, insert this if statement:

if (platformPrOptions.requireTestsForPlatformAutomerge && !testsPresent) {
        logger.debug(
          'requireTestsForPlatformAutomerge is enabled and tests are not present, skipping automerge',
        );
        return;
}