GeezerVison

It was already in its own job:

This PR:

Would it be more accurate to say this moves the job to its own workflow + file?

Benefits:

• Makes the top-level build.yml shorter.
• Helps make each bit more modular, separating config.
• Are there other benefits of this change?

Costs:

• This PR does add a net 46 lines of config, mainly passing the outputs from the new job out through the new workflow, though it's not too complex.
• We get another "dummy" reusable workflow showing in the left menu, with no workflows shown when clicking (although the pinning does help find the important ones, thanks for letting me know about pinning):

Would it be more accurate to say this moves the job to its own workflow + file?

Yes, you're right. I must've phrased it better.

Benefits:

• Makes the top-level build.yml shorter.

• Helps make each bit more modular, separating config.

• Are there other benefits of this change?

I think these benefits have a significant impact on their own. This also contributes to the separation of the structure / triggers vs. implementation details. In the future, it makes it cleaner to add more jobs (or separate what's in there already) if the need be. I feel like it currently computes several things that aren't necessarily related enough to be in the same job.
My idea is that the top-level workflow structure should be in the main configuration file, and the components would be separate, only interfacing through their inputs/outputs.
It's basically an abstraction layer separation exercise.
Having such predictable structure will also enable us to introduce linting that would keep it consistent and easy to reason about.

Costs:

• This PR does add a net 46 lines of config, mainly passing the outputs from the new job out through the new workflow, though it's not too complex.

• We get another "dummy" reusable workflow showing in the left menu, with no workflows shown when clicking (although the pinning does help find the important ones, thanks for letting me know about pinning):

Yes, you're right. I suppose, we could add names to those reusable workflows with something along the lines of “Don't click”. Combined with pinning the entry-point workflows, that would make it look nicer. Personally, I'm not too worried about these, but I see how some of the points may annoy people.

Additionally, it may make sense to hit GitHub support with a request to hide workflows that only have a workflow_call trigger, since it's known that those are never going to have any runs listed.

P.S. Regarding having a nested entry in the sidebar — I don't expect that many people would need to click on that, so it'll remain collapsed and green most of the time, not really affecting anyone on the scale.

@picnixz this also needs backport labels FYI

Yes, I agree on balance this makes it things a bit clearer. Thanks!

Thanks @webknjaz for the PR, and @hugovk for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

Sorry, @webknjaz and @hugovk, I could not cleanly backport this to 3.12 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker e60ee11cb51b87deeb22ad125717bd0d0dc10fa8 3.12

GH-122510 is a backport of this pull request to the 3.13 branch.

GH-122538 is a backport of this pull request to the 3.12 branch.