github/workflows: attempt to enable CI for merge queue

[jeeb]

No description provided.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[kasper93]

What's missing

• require all the checks that we run. There is no reason to cherry-pick some
• don't forget about https://github.com/mpv-player/mpv/blob/f94b44c8e5d4d15a5b102b13adba4ed25fb14128/.github/workflows/fuzz.yml
• set merge queue to 2h, because if we starve our runners it may take longer than 1h, me think. openbsd build takes 15 minutes, fuzzing takes over 40 minutes. But there are a lot of linux runners 20, so we manage to eat this time, but I noticed win32 can sometimes also wait, because there are only 5 runners. Fuzzing can be made to 10 minutes, but the main bottleneck is the build time really, so it would be still be over 30 minutes. I guess we will see if this is a problem. It will build everything on queue again, so kinda more load...

[sfan5]

If I understand correctly this will invoke a new build for every PR to be merged.
However the fuzzing runs regularly take up to 1 hour. Adding so much delay is not acceptable.

Also that fact that we can't merge any PRs when msys inevitably breaks again in some way will come back to bite us.

[kasper93]

Adding so much delay is not acceptable.

Care to explain why? This feature is precisely designed, so you don't have to wait/look at the paint dry and just click "merge when ready" and forget. Also I never seen that we rush to merge any PR, where any delay would be critical for the workflow.

However the fuzzing runs regularly take up to 1 hour.

To be exact 47 minutes, 23 for build and 23 for fuzzing. Fuzzing could be reduced to 10 minutes like I said above. But this would still be 37 minutes, not much win. We have constant build time unfortunately.

when msys inevitably breaks again

in which case fixing CI should be priority probably. But anyway, we can make only some of the checks required. Though in practice this probably beats the purpose of this whole exercise, because if we allow accidental breaks, we might as well don't bother enabling it. I'm saying this in most positive way, there are few annoying things about this queue system that we might not want to fight with. And in practice, except little convenience it won't change the way we merge prs really...

EDIT: We could make it even other way around, do fuzzing jobs only on merge_queue trigger. Not sure if this is possible. Because from what I've seen few days ago is that, it waits for required checks on pull_request trigger, before starting merge. So likely both needs to pass. Which is another annoyance tbh.

[sfan5]

Care to explain why?

There's no process reason why, I was just thinking it's annoying to have such a large delay from "I want to merge this" to the commit actually appearing in the repo.
"so much delay is not acceptable" sounds very strong and I don't know why I wrote it like that

in which case fixing CI should be priority probably.

Priority sure but not a requirement. If I want to merge a small fix I should not be forced to figure out the msys issue or temporarily disable it.
I know I could just push it directly but I still think it's suboptimal.

[Dudemanguy]

Is it possible to ignore failures on certain steps in the job? Like if the build step fails, that's obviously a no-no and should be fixed. But if the container just derps out for some random reason, that's not a blocker.