Promote free-threaded CI

[itamaro]

Feature or enhancement

Proposal:

I propose to promote the existing free-threaded GitHub Actions CI, following the official acceptance of PEP 703, including:

1. Change the triggering of the free-threaded jobs to always trigger, instead of conditionally on the presence of the topic-free-threaded label.
2. Remove the free-threaded jobs from the list of allowed failures (aka require that these jobs pass to get green signal).

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

https://discuss.python.org/t/is-it-time-to-promote-free-threaded-ci-and-buildbots/39064

Linked PRs

• GH-112245: Promote free threaded CI #112246

[terryjreedy]

I presume it would always fail and would have to be ignored. Given that, why waste the resources? Anyone interested in checking how much failure should run as desired -- and this should be an option, say with a comment.

[itamaro]

I presume it would always fail and would have to be ignored. Given that, why waste the resources?

why would it always fail?
it is being used for opt-in testing on free-threaded-related PRs (using the label), and has been passing quite consistently.
also the buildbot Linux & MacOS builders have been very stable over the last few weeks (I proposed to mark them as stable). only the Windows buildbot is unstable, and that's a known issue that's pending on some packaging-related changes.

[terryjreedy]

I just added 'topic: free-threading' to a PR I expect to update today, triggering a test. I am curious what happens with test_idle. If it passes, I will do a local FT rebuild and run IDLE itself.

[colesbury]

The "free-threaded" builds run with the GIL. They are not actually "free-threaded" and won't be until all the pieces are in place. We are basically doing the following for --disable-gil builds for 3.13:

1. Integrate the pieces of PEP 703, but with the GIL enabled. There's still a lot of value in the building and testing because many bugs from new code show up even with the GIL enabled and we want to make sure the #ifdef Py_NOGIL code paths work. At this point (now), both the CI and local --disable-gil builds always run with the GIL enabled.
2. After most of the pieces are integrated, we start testing locally with the GIL disable via an environment variable switch and fix the inevitable bugs. At this point the --disable-gil CI still runs with the GIL enabled, but increasingly the local testing of --disable-gil builds will be with the GIL disabled.
3. Once the local builds and tests are stable, we switch the --disable-gil CI to run with the GIL disabled.