Avoid re-running CI if merge queue is empty and a merged PR is up-to-date

[sgrzeszc]

Select Topic Area

Question

Body

My team's CI uses a merge queue group size is 1 and we're running exactly the same checks for PRs while they are in review and when they are in the merge queue.

If the queue becomes empty, and we have a freshly approved PR which is up-to-date with the target branch and has all checks passing, adding it to the queue causes all the checks to be re-run, even though this is a waste of time and compute.

Is there a way to avoid this specific scenario - have the queue checks be skipped if the PR does not need to be modified?

[ayushraistudio]

Hi @sgrzeszc,

This behavior is actually intended by the Merge Queue design to guarantee safety, even though it can feel redundant in this specific scenario.

When a PR enters the queue, GitHub creates a temporary merge commit to verify the integration in the current state of the queue (ensuring serialization). Even if your PR is visually up-to-date with the target branch, the system enforces this fresh check to prevent any race conditions before the final merge.

Is there a way to skip it?
Currently, there isn't a native setting to "skip checks if up-to-date" specifically for the queue entry event, because the queue treats this context differently than a standard PR check.

Recommended Workaround:
The best approach right now is to rely on aggressive caching (e.g., using actions/cache or your CI provider's caching layer). Since the code hasn't changed, the cache should hit, making these re-runs complete in seconds rather than minutes.

Hope this clarifies why the system behaves this way!

[sgrzeszc]

The cache is an interesting avenue to explore. Thanks!

[willlma]

I looked into this and it doesn't seem like a merge group can use a cached results from a PR run. So you'll never have a cache hit. Is that what you discovered as well?

[ayushraistudio]

Hi @willlma,

Thanks for pointing this out!

My suggestion was to explore caching as a way to reduce CI execution time, not necessarily to reuse PR test results directly in the merge queue.

You're right that GitHub Actions cache scoping can prevent a merge-group run from accessing a cache created by a PR run. However, caching dependencies or using a remote build cache may still help reduce redundant setup and build work.

I agree that this doesn't solve the original issue of skipping merge-group checks entirely. As far as I know, GitHub doesn't provide a native option to skip required merge-group checks just because a PR is already up to date.

So, caching is a potential optimization rather than a guaranteed solution to the original problem.