gh-145098: Run Apple Silicon macOS CI on macos-26 (Tahoe)

[clintonsteiner]

• Issue: CI: move Apple Silicon macOS workflows to macos-26 (Tahoe) #145098

[hugovk]

I'm curious if there's any performance difference between this and the previous one, can you compare times?

Also noting this image is still in beta but should be GA "around November" [2025], "before Xcode 26.3 releases" [20 Feb], "late February / early March, but depends on Xcode 26.4 behavior in general, so no promises".

actions/runner-images#13008

I don't see this as a blocker as long as everything we need is in there.

[hugovk]

Job	macos-14 (main)	macos-26 (PR)	Diff
build and test	8m 39s	12m 11s	+3m 32s (+41%)
free-threading build and test	15m 58s	18m 25s	+2m 27s (+15%)
Android (aarch64)	4m 09s	3m 34s	-35s (-14%)
iOS	16m 29s	21m 34s	+5m 05s (+31%)
JIT aarch64 (Debug)	15m 43s	15m 04s	-39s (-4%)
JIT aarch64 (Release)	15m 36s	13m 09s	-2m 27s (-16%)
tail-call aarch64	9m 54s	9m 45s	-9s (-2%)

[webknjaz]

Bumping the OS seems fine, although the downloader refactoring feels standalone..

[freakboy3742]

My concern is less about speed, and more about reliability.

For background - there is no issue running CPython on macOS-26. This is entirely a GitHub Actions issue.

The macOS-15 runner has proven to be massively unreliable, and I haven't seen any movement on actions/runner-images#12777 or actions/runner-images#13275/actions/runner-images#13459 that suggests those issues have been fixed.

Before this lands, I'd want to see a dozen or so re-runs to give some confidence that the simulator boot reliability issues we've seen on macOS-15 have been resolved on macOS-26.

I also share the concern about conflating the downloading change with the CI change - is there a direct connection with the macOS runner here? The comment about "some runner/proxy setups" suggests it might be... but it's not clear if this is only to address an issue you've seen locally.

[clintonsteiner]

I changed the download run probably due to unreliability of the runner, failed downloads twice and didn't know if it was a regression in the os of the runner's curl capability @freakboy3742

[freakboy3742]

I changed the download run probably due to unreliability of the runner, failed downloads twice and didn't know if it was a regression in the os of the runner's curl capability @freakboy3742

GitHub Actions failing downloads is a fairly common, but entirely inconsistent phenomenon. I've seen errors from GitHub accessing GitHub downloads. Unless you have concrete evidence that the issue is HTTP 1.1 compliance, I'd rather not complicate that section of code (or at least defer it to a separate PR, where we can address the same issue on other platforms like Android and Emscripten).

[clintonsteiner]

@freakboy3742 agreed, I had just pushed a revert a minute ago actually

[hugovk]

@clintonsteiner Please can you resolve the conflict in jit.yml?

And revert the unrelated changes to Include/internal/pycore_dict.h and Objects/dictobject.c?

27b3fa0

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[clintonsteiner]

@hugovk done, thank you!

[savannahostrowski]

LGTM for jit.yml but also in general!

[freakboy3742]

Broadly looks good; a couple of specific suggestions that might impact testing time. All evidence I've seen says there's a very restricted set of images that are pre-warmed, and that pre-warming is good for up to 10 minutes of test time.

I also want to see the iOS job pass a dozen times in succession before this is merged - historically, GitHub's iOS runners are very inconsistent, and I don't want to merge this only to have to revert it because it didn't trigger

[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.

And if you don't make the requested changes, you will be poked with soft cushions!

[clintonsteiner]

I have made the requested changes; please review again.
Or more specifically, thanks to @freakboy3742 for pushing suggestions

[bedevere-app]

Thanks for making the requested changes!

@savannahostrowski, @freakboy3742: please review the changes made to this pull request.

[freakboy3742]

@clintonsteiner Please don't force-push to branches - when you do that, we lose all the history of past commits. We use squashed commits when a PR is accepted, so there's no problem with having a "dirty" commit history on a PR.

I was in the middle of doing some stress testing of the CI - and, as suspected, on the 9th re-run of the iOS test suite, we got the failure that there are "no matching simulators". So - as I feared, there's about a 10% failure rate associated with the macOS-26 runner, which matches what we saw with the macOS-15 runner, but doesn't happen with the macOS-14 runner.