CI: silent merge check

m3dwards commented at 2:53 pm on August 6, 2025: contributor

With the upcoming potential migration to cirrus runners (#32989) we need a way to periodically check for a silent merge conflict. Cirrus CI currently does this every week.

This is part of a proposal that will look for a label on a PR as a trigger to run the lint and get_previous_releases test. This label could be added manually or better, Drahtbot could periodically add (and remove) this label.

~~An example of this running on a test org: https://github.com/testing-cirrus-runners/bitcoin/actions/runs/16780213204/job/47516540034~~

Updated 4th March 2026

In this design there is a new GHA job merged into the main repo that adds check runs to each PR on whether they have a silent merge conflict or not.

The idea is that we have a job that pretty much runs 24/7 triggered every 6 hours or so and set to run for 5.5 hours, it could be set to run on a GHA runner rather than a Cirrus runner. Obviously running on a Cirrus runner (or even multiple runners) would dramatically speed up how many PRs can be checked for silent merge conflicts.

The job uses the Github checks API to add a passing or failing test run to each PR directly. The silent merge check job itself should always pass, it writes pass or fail checks to the PRs.

It will look through all open PRs and discard anything that has a git merge failure or a failing test with the thinking that there is no point checking something that can’t be merged anyway. Then it will select PRs that have not had a silent merge check and one by one pull the merge branch of the PR and the full CI job “Previous releases” on that branch.

When all PRs have been checked it will then re-check a PR that was checked the longest time ago.

Things that can be tweaked:

Could run on multiple runners simultaneously rather than just one How long the job is allowed to run for (currently 5.5 hours, GHA runners have a limit of 6) How frequently the job is triggered What type of runner to run the job on The ordering of how to select the next PR to check. What things trigger the job to skip a PR (currently failing tests and merge conflicts) Some back of the envelope maths with the “Previous Releases” job taking 10/15 minutes with a primed cache on a Cirrus runner and 300 open mergeable PRs (probably overestimate) the job would be checking each PR roughly every 4 days.

DrahtBot added the label Tests on Aug 6, 2025

DrahtBot commented at 2:53 pm on August 6, 2025: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33145.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept ACK	fjahr

If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

Conflicts

No conflicts as of last run.

in .github/workflows/silentmerge.yml:39 in 1b5747233f

34+            echo "::notice title=Runner Selection::Using GitHub-hosted runners"
35+          fi
36+
37+  previous-releases:
38+    name: 'Previous releases, depends DEBUG'
39+    if: contains(github.event.label.name, 'PeriodicMergeCICheck')

maflcko commented at 3:09 pm on August 6, 2025:

Seems fine, but currently a vector of task names is accepted, see --task in https://github.com/maflcko/DrahtBot/blob/2038d4d541b89bf2601614b5656d7d30d73e17be/rerun_ci/src/main.rs#L7-L23

It would be good to allow the same somehow?

m3dwards commented at 2:29 pm on August 7, 2025:

Can you elaborate a little more on what this would look like? Would this be different labels for different jobs? As in a label that runs the Previous Releases job and a different label that would run a different job?

maflcko commented at 2:40 pm on August 7, 2025:

I don’t know. Not sure if we want to see pull requests spammed with “added and removed” label events (https://github.com/testing-cirrus-runners/bitcoin/pull/19#event-19014793971).

GitHub doesn’t make this easy and I wonder if we may want to just spin our own CI to detect silent merge conflicts.

maflcko commented at 2:56 pm on August 7, 2025:

To give some more context: We are now trying to add 200+ lines of code to this repo which have to be maintained, but they cause label spam, and likely aren’t sufficient to achieve the goal, because the ci-failed notification will go to the one adding the label and triggering the workflow?

If so, we’d have to create a comment (or other notification) anyway. So if additional glue code is needed, we might as well handle all code externally.

m3dwards commented at 4:14 pm on August 8, 2025:

It’s a fair comment. I’ll see what the ci-failed notification could look like but you could be right that this approach is less than ideal. @0xB10C has suggested perhaps merging this into the main CI file but might come with a verbose predicate before each job.

maflcko commented at 3:32 pm on August 20, 2025:

Yeah, merging this with the main CI file is certainly better, if possible. However, it still leaves the issue of label spam. Also, it needs to be confirmed to be working correctly (to send the failed-notification to the right person)

Sammie05 commented at 7:54 pm on August 6, 2025: none

Nice work on this! The label-based trigger for PeriodicMergeCICheck is a clean approach.

One thought though since this is driven by label events, do we need to consider cases where multiple labels are applied at once? Would the condition still behave as expected?

Also agree with the suggestion from @maflcko having a vector of task names could as well improve flexibility

maflcko commented at 8:32 am on August 7, 2025: member

Other stuff to check would be that this works at all and doesn’t just re-run an ancient commit, like #32989 (comment)

m3dwards commented at 2:26 pm on August 7, 2025: contributor

Other stuff to check would be that this works at all and doesn’t just re-run an ancient commit, like #32989 (comment)

Just ran a test to specifically test for this by updating the default (master) branch and adding and removing the label and it correctly picked an updated merge commit based on the PR merged into the updated master.

0xB10C commented at 10:41 am on August 8, 2025: contributor

Have you considered doing something like the following in .github/workflows/ci.yml to avoid having to maintain separate files?

 0name: CI
 1
 2on:
 3  push:
 4  pull_request:
 5    types: [opened, reopened, synchronize, labeled]
 6
 7jobs:
 8  conditional-job:
 9    if: >
10      github.event_name == 'push' ||
11      (
12        github.event_name == 'pull_request' &&
13        (
14          github.event.action == 'opened' ||
15          github.event.action == 'reopened' ||
16          github.event.action == 'synchronize' ||
17          (
18            github.event.action == 'labeled' &&
19            contains(github.event.label.name, 'PeriodicMergeCICheck')
20          )
21        )
22      )
23    runs-on: ubuntu-latest
24    steps:
25      - run: echo "Running CI job"

m3dwards commented at 4:10 pm on August 8, 2025: contributor

Have you considered doing something like the following in .github/workflows/ci.yml to avoid having to maintain separate files?

Could be a good shout, seems a bit of a verbose check if that has to be included in each job. I’ll have a think about it. This is exactly the type of feedback that’s good to consider.

DrahtBot added the label Needs rebase on Sep 3, 2025

maflcko commented at 9:43 am on September 4, 2025: member

concept ack, but I don’t have the slightest idea if this is even possible (or how) with GHA

m3dwards commented at 1:26 pm on September 4, 2025: contributor

Currently working on an alternative approach of one job that loops through PRs, might close this PR in favour of the other one based on feedback.

maflcko commented at 7:29 am on October 16, 2025: member

Any updates here? Just asking, because it is a bit tedious to manually search for all silent merge conflicts. Example ref: #29136 (comment)

fjahr commented at 4:47 pm on November 21, 2025: contributor

Concept ACK

maflcko commented at 4:52 pm on November 21, 2025: member

I think what could work (hacky, untested):

Setup a separate “silent-merge-check” repo with the desired ci config
Push the selected ci runs to it on the desired schedule
Get the result, and on failure, pass it back to the upstream repo

fanquake commented at 11:40 am on February 13, 2026: member

@m3dwards are you still working on something here? My understanding is that this is still an issue.

m3dwards commented at 4:21 pm on February 16, 2026: contributor

I haven’t been working on it but happy to pick this back up

m3dwards force-pushed on Mar 4, 2026

m3dwards commented at 1:17 pm on March 4, 2026: contributor

I wanted to share my current direction and thinking on this and have pushed some example code and can show some test runs on my fork. I think it’s a good point to get some feedback if we think this is a good general direction.

In this design there is a new GHA job merged into the main repo that adds check runs to each PR on whether they have a silent merge conflict or not.

The idea is that we have a job that pretty much runs 24/7 triggered every 6 hours or so and set to run for 5.5 hours, it could be set to run on a GHA runner rather than a Cirrus runner. Obviously running on a Cirrus runner (or even multiple runners) would dramatically speed up how many PRs can be checked for silent merge conflicts.

The job uses the Github checks API to add a passing or failing test run to each PR directly. The silent merge check job itself should always pass, it writes pass or fail checks to the PRs.

It will look through all open PRs and discard anything that has a git merge failure or a failing test with the thinking that there is no point checking something that can’t be merged anyway. Then it will select PRs that have not had a silent merge check and one by one pull the merge branch of the PR and the full CI job “Previous releases” on that branch.

When all PRs have been checked it will then re-check a PR that was checked the longest time ago.

Things that can be tweaked:

Could run on multiple runners simultaneously rather than just one
How long the job is allowed to run for (currently 5.5 hours, GHA runners have a limit of 6)
How frequently the job is triggered
What type of runner to run the job on
The ordering of how to select the next PR to check.
What things trigger the job to skip a PR (currently failing tests and merge conflicts)

Some back of the envelope maths with the “Previous Releases” job taking 10/15 minutes with a primed cache on a Cirrus runner and 300 open mergeable PRs (probably overestimate) the job would be checking each PR roughly every 4 days.

Please see a run of the job on my fork here: https://github.com/m3dwards/bitcoin/actions/runs/22670080789 A PR that passed the silent merge check: https://github.com/m3dwards/bitcoin/pull/6 A PR that failed the silent merge check: https://github.com/m3dwards/bitcoin/pull/5 (I modified my master branch to have a change that would silently fail against that PR)

This is what a failing check would look like in the PR:

m3dwards force-pushed on Mar 4, 2026

DrahtBot added the label CI failed on Mar 4, 2026

ci: added silent merge check ef3ea7636e

m3dwards force-pushed on Mar 4, 2026

DrahtBot removed the label CI failed on Mar 4, 2026

DrahtBot removed the label Needs rebase on Mar 4, 2026

CI: silent merge check #33145

Code Coverage & Benchmarks

Reviews

Conflicts