Repository navigation
Use windows-2025 in GitHub Actions #150605
Description
Currently we are using windows-2025-vs2026 which is no longer in public beta:
The images have passed the beta stage.
windows-2025 will use Windows Server 2025 with Visual Studio 2026 image in June 2026:
This change will be rolled out over a week beginning June 8, 2026 and will complete by June 15, 2026.
So some time after the rollout we should switch, but no rush, yet.
Activity
[-]Use windows-2025 in Github Actions[/-][+]Use windows-2025 in GitHub Actions[/+]GH-150605: use windows-2025 in GitHub Actions (#150606)
[3.15] GH-150605: use windows-2025 in GitHub Actions (GH-150606) (#15…
hugovk commentedon Jun 24, 2026
We've now replaced
windows-2025-vs2026withwindows-2025, inmainand3.15.Do we want to upgrade older branches, for example from
windows-2022towindows-2025?cpython/.github/workflows/reusable-windows.yml
Line 27 in 59ff73a
We do need to keep the CI working until each branch goes EOL, and GitHub normally maintain two OS versions so
windows-2022will likely not last long enough.chris-eibl commentedon Jun 24, 2026
We'd need to backport #144680 then, because AFAIK in
windows-2025only VS2026 and its associated PlatformToolSet v145 is installed. IOW, the currently used v143 (VS2022) is no longer available there.I've asked @zooba back then about backporting after an observation period on main, and got this answer:
So I think we should (must?) do that, but maybe not now?
This might also be an issue when building the official binaries. We use the Azure VM image
windows-2025there for the older builds and override withwindows-2025-vs2026for 3.15 (because VS2026 is needed for the tail-calling builds).zooba commentedon Jun 24, 2026
Updating the CI builds isn't as risky as updating the release builds, and we'll still have buildbots running (in case someone introduces a compiler feature that doesn't exist earlier), so I'm not opposed to updating the GitHub CI.
Backporting the default platform toolset code is also fine, provided we aren't changing values that are already there. But you might want to define
PlatformToolset: v145in the CI definition (I do that for my private builds and everything works).chris-eibl commentedon Jun 25, 2026
Ah, yes, for my local builds I've also opted in before #144680. We'd just get the
and (to me) that's a wart (and confusing if we'd really switch to use
v145for the official binaries but keep that warning in the build logs).I did not find exact EOL for runner images, but strong hints that even when regular support for the operating system Windows Server 2022 ends in October 2026, this does not mean the GH action runner images are ditched.
So plenty of easy options and no urgent action needed here.
We can just wait and see when CI or release builds start to fail for the older branches and then react?
hugovk commentedon Jun 25, 2026
Indeed, GitHub has an "N-1" OS support policy:
So some time after
windows-202x(or whenever it's called) is out,windows-2022will go EOL.Yes, we can wait. The oldest branches can likely ride out on
windows-2022.Shall we close this issue until then?
pythonGH-150605: use windows-2025 in GitHub Actions (python#150606)