Tracking Issue for evaluating `macos-26` runner images

[jieyouxu]

Summary

GitHub Actions Runner Images have a N-1 OS support policy. Old EOL runner images will be removed after typically 6 months of deprecation or EOL (though timelines can be accelerated) [1]. There are currently (as of 2026-06-10) 3 macOS runner images, {macos-14, macos-15, macos-26}. macos-14 will be removed on 2026-11-02 [2], and so macos-15 will then become the oldest supported macos version.

Previously we tried the running time if we run aarch64-apple-equivalent workload on macos-26 runner images, and previous attempt(s) timed out. I tried running the job again recently and it seems to be able to build under the usual aarch64-apple running time.

We will experiment with running aarch64-apple-equivalent workload on macos-26 runner images in parallel to the existing aarch64-apple macos-15 test job to gather more datapoints on its run performance. Dist jobs will continue to be built from macos-15 runner images for the time being.

Whether and when to actually make the switchover to macos-26 runner images is orthogonal to this experiment, and will be evaluated separately. This is precursor work.

Steps

• Create a aarch64-apple-equivalent test job aarch64-apple-macos-26 which runs on macos-26 runner images, and run it in parallel to the existing macos-15-based aarch64-apple job. Create experimental test job aarch64-apple-macos-26 for evaluating macos-26 runner images #157688
• Monitor running time of the test job over approximately a week or two.
• Evaluate job performance at around 2026-06-19. We will consider whether to keep running them in parallel, or work towards transitioning macos jobs to macos-26 then.
• Update comment in jobs.yml following outcome of above.

Relevant discussions

• #t-infra > GHA macos-26 slowness

Investigation log

• ❌ ci: use macos-26 for aarch64-apple job #152842 timed out.
• ❌ [EXPERIMENTAL] ci: use macos-26 for aarch64-apple job #157231 timed out.
• ✅ [EXPERIMENTAL] Do not look (part 2) #157258, seems to finish in reasonable time even with --set build.cccache=false.