Also found here: #48792

That's not what the issue here is - the issue is that when a PR is already up-to-date and at head of queue, there's nothing to be gained from re-running the checks while it's in the merge queue.

We at @cariad-tech built a GitHub Action that makes skipping CI checks in the merge queue possible whenever the code hasn't changed: https://github.com/cariad-tech/merge-queue-ci-skipper

As a note for people who might use this: this could cause issues since someone could merge a PR based on an old trunk that wouldn't pass tests on the new trunk, and it would be let in since the MQ skips it.

You'll need to force your branch to be up to date with the branch you're merging to and make that a mandatory check before the PR can be allowed to merge into the queue. The code above skips the step in the PR but not on MQ.

We at @cariad-tech built a GitHub Action that makes skipping CI checks in the merge queue possible whenever the code hasn't changed: https://github.com/cariad-tech/merge-queue-ci-skipper

If you have that if condition on a required check, you will need to create a duplicate check with the same name with if: ${{ github.event_name == 'merge_group' }} which always passes by returning true. GH is looking for an explicit success from a required check of that name. You may have to create a separate workflow file for this with a merge_group trigger.

But just as note, the only case where it's perfectly safe to do this is if the PR is both up-to-date with trunk, and there's nothing in the MQ. (If you're just looking to skip an entire workflow on MQ, that can be done with the above method, but that case is not what this discussion is about)

But the skipped status is not considered a success

Yes it is. From here: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks

Note: A job that is skipped will report its status as "Success". It will not prevent a pull request from merging, even if it is a required check.

Yes it is.

That's about what a skipped job behaves like, not a skipped workflow.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks#handling-skipped-but-required-checks

@lesaux
lets say running tests costs a few 100$ per run, than it makes sense to only execute in the mergequeue when the turn of the branch is reached. All test results before are worhtles, as new features might be merged, and you need to rebase before merging.

Looking at latest supply-chain-attack issues with actions this seems like asking yourself for a breach tbh:

"This Software / Contribution is unfinished, untested and is in particular not in a state to be used in any productive or series context. It is provided as a starting point for further development and any use requires extensive checks, improvements and testing, for which exclusively the user integrating this OSS shall be responsible."

Please dont propose solutions that you dont fully stand behind and can support.

It’s been in use for about a year now in our project. The disclaimer is a requirement from our legal department. I’ll personally do my best to make sure it keeps working.

If in doubt, please feel free to copy the action.yml into your own project.

+1. We are giving up merging queues because of this. It is very difficult to work around it CircleCI checks.