gh-110793: Add CI job that runs tests with an installed build - #152664
Conversation
|
This is currently blocked by #152653 (failing |
|
Hi! Anyone have any comments on this? |
webknjaz
left a comment
There was a problem hiding this comment.
Looks good in general. I have an inline question, though. Non-blocking.
itamaro
left a comment
There was a problem hiding this comment.
do you have an example of a breakage that would be caught by this CI job, and not by any other existing CI job?
| if: needs.build-context.outputs.run-ubuntu == 'true' | ||
| uses: ./.github/workflows/reusable-install.yml | ||
| with: | ||
| os: ubuntu-26.04-arm |
There was a problem hiding this comment.
why use arm specifically? (vs plain x86_64 ubuntu)
There was a problem hiding this comment.
The architecture shouldn't really mater, however, it's generally the fastest runner, that's why we enable -ucpu when running tests on it:
cpython/.github/workflows/build.yml
Lines 236 to 240 in 998b890
There was a problem hiding this comment.
A little late to the party but I'd like to state FTR that in the future we should be adding an explicit comment explaining such choices. The motivation may otherwise be difficult to trace transparently and figure out, when troubleshooting something in the future.
For example, #152653 which prompted this. I don't know any more specific examples of the top of my head, but there have been quite a few cases of this. |
| with: | ||
| os: ubuntu-26.04-arm |
There was a problem hiding this comment.
We're not varying this, so it doesn't need to be a variable.
| with: | |
| os: ubuntu-26.04-arm |
There was a problem hiding this comment.
Honestly, I think things like this might be useful in terms of surfacing the same type of information on the same level of abstraction (the calling workflow). But it's probably something to be debated in a separate refactoring effort anyway..
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
hugovk
left a comment
There was a problem hiding this comment.
Thanks!
Noting for future reference, this new job takes around 6 minutes, much quicker than the current bottleneck (Windows x86 FT) at almost 30 minutes.
https://github.com/python/cpython/actions/runs/31373039414/job/93406279180?pr=152664
|
Thanks for all the reviews! |
|
Thanks @StanFromIreland for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
|
Thanks @StanFromIreland for the PR 🌮🎉.. I'm working now to backport this PR to: 3.15. |
|
Thanks @StanFromIreland for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
|
GH-155482 is a backport of this pull request to the 3.13 branch. |
|
GH-155483 is a backport of this pull request to the 3.15 branch. |
|
GH-155484 is a backport of this pull request to the 3.14 branch. |
This takes into consideration the suggestions on #110794.
As for timing, I picked the fastest runner available, we'll have to see how long it takes. I presume it won't be slower than the Windows builds, however.Looking at the three runs on this PR, it takes about nine minutes (however, that does include two 30s timeouts). That's far faster then our longest runs which are around half an hour.