-
-
Notifications
You must be signed in to change notification settings - Fork 32k
gh-111062: Reusable Ubuntu build that supports free-threaded mode as the conditional CI #111452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
edited by bedevere-app
bot
- Issue: Add GitHub Action for checking free-threaded build #111062
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 |
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 |
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 |
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 |
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 |
.github/workflows/build.yml
Outdated
build_ubuntu_free_threaded: | ||
name: 'Ubuntu (free-threaded)' | ||
needs: check_source | ||
if: needs.check_source.outputs.run_tests == 'true' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should check that the label is attached or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please skip the test if the label is not attached
https://github.com/python/cpython/pull/111452/files#r1375408558
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now it looks good to me
@hugovk @ezio-melotti Can you please take a look?
I'll add the https://github.com/python/cpython/labels/topic-free-threaded label to check if it triggers. |
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
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. |
I know this issue, but And as I commented before, I don't want that |
And it's intended design at this moment, or we need to improve it at later |
And simply re-open the PR will works if the person miss the timing of the labeling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Thanks for the help @corona10 :-) |
…de as the conditional CI (python#111452) Co-authored-by: Donghee Na <donghee.na92@gmail.com>
…de as the conditional CI (python#111452) Co-authored-by: Donghee Na <donghee.na92@gmail.com>
…de as the conditional CI (python#111452) Co-authored-by: Donghee Na <donghee.na92@gmail.com>