gh-111062: Reusable Ubuntu build that supports free-threaded mode as the conditional CI

[NCLI]

• Issue: Add GitHub Action for checking free-threaded build #111062

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[corona10]

We should check that the label is attached or not.

[corona10]

Please skip the test if the label is not attached
https://github.com/python/cpython/pull/111452/files#r1375408558

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[corona10]

Now it looks good to me
@hugovk @ezio-melotti Can you please take a look?

[hugovk]

I'll add the https://github.com/python/cpython/labels/topic-free-threaded label to check if it triggers.

[hugovk]

The label would need to have been added before the workflow runs, which means you need to add it when drafting the PR or do it very quickly.

Or we need to add triggers similar to this:

cpython/.github/workflows/require-pr-label.yml

Lines 3 to 5 in fa35b9e

	on:
	pull_request:
	types: [opened, reopened, labeled, unlabeled, synchronize]

But that adds extra complexity because we don't want to re-trigger all the other CI jobs.

---

More to the point: do we really need to limit this via a label?

Should we always run it?

After all, we want to make sure there are no regressions for both the GIL and free-threaded builds, whether or not someone considers their PR to somehow related free-threaded.

[corona10]

The label would need to have been added before the workflow runs, which means you need to add it when drafting the PR > or do it very quickly.

Or we need to add triggers similar to this:
More to the point: do we really need to limit this via a label?
Should we always run it?

I know this issue, but topiuc-free-thread works are not a big portion of over all PRs so I think that it can be taken into account anyway at this moment. In the near future it can be run anyway once the free-thread version becomes stable but looks like not this moment. :)

And as I commented before, I don't want that free-threaded work to make other people's work stop.

[corona10]

The label would need to have been added before the workflow runs, which means you need to add it when drafting the PR or do it very quickly.

And it's intended design at this moment, or we need to improve it at later

[corona10]

And simply re-open the PR will works if the person miss the timing of the labeling

[hugovk]

Thanks, let's merge this.

We can remove the label-handling later when we're all ready for it.

Let's also consider the YML file names later, once the Windows one is also done.

And at the same time we can see about naming the "build_x" bit (the third part in "Tests / OS / build_x") in a nicer and more consistent way:

PS We'll need to backport all of these PRs to 3.11/3.12 -- but obviously not the free threaded part. And we can take care of that later too.

[NCLI]

Thanks for the help @corona10 :-)