windows-2025-vs2026 jobs in the same workflow run resolved to different image versions, breaking MSVC LTCG linking

[chsbuffer]

Description

MSVC /GL and /LTCG artifacts require the producer and final linker to use a compatible MSVC toolset. In this workflow, static .obj / .lib artifacts produced by one job are linked by a later job. If jobs using the same runner label receive different Visual Studio / MSVC
toolset versions, link-time code generation can fail with compiler IL mismatches or unresolved MSVC STL internals.

In a single GitHub Actions workflow run, multiple jobs using the same runner label windows-2025-vs2026 were assigned different concrete runner image versions:

• 20260510.103.1
• 20260518.113.1

This caused artifacts built with MSVC 14.51 to be consumed by a link job running MSVC 14.50, and the final link failed.

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 22.04
• Ubuntu 24.04
• Ubuntu Slim
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• macOS 26
• macOS 26 Arm64
• Windows Server 2022
• Windows Server 2025
• Windows Server 2025 with Visual Studio 2026

Image version and build link

https://github.com/chsbuffer/HostForge/actions/runs/26225216886

Is it regression?

no?

Expected behavior

Expect multiple jobs in the same workflow run using the same runs-on label receive the same runner image version.
This expectation is based partly on the previous issue #8697, where inconsistent image resolution for the same runs-on label was reported and closed as fixed.

Actual behavior

All affected Windows jobs used:

runs-on: windows-2025-vs2026

However, jobs in the same workflow run received different concrete runner image versions.

Job	Image version
pack-skia-static (11.0, 2.88.9)	20260510.103.1
pack-skia-static (12.0, 3.119.2)	20260510.103.1
windows-hostlibs (arm64, win-arm64, 10.0, default)	20260518.113.1
windows-hostlibs (arm64, win-arm64, 10.0, no-pgo, --no-pgo)	20260518.113.1
windows-hostlibs (x64, win-x64, 10.0, default)	20260510.103.1
windows-hostlibs (x64, win-x64, 10.0, no-pgo, --no-pgo)	20260510.103.1
windows-skia (arm64, win-arm64, 2.88.9)	20260510.103.1
windows-skia (arm64, win-arm64, 3.119.2)	20260510.103.1
windows-skia (x64, win-x64, 2.88.9)	20260510.103.1
windows-skia (x64, win-x64, 3.119.2)	20260518.113.1
pack-static-apphost	20260510.103.1
windows-link-avalonia (11.0, 2.88.9)	20260510.103.1
windows-link-avalonia (12.0, 3.119.2)	20260510.103.1
windows-matrix-test	20260510.103.1

Repro steps

1. Create a workflow with multiple Windows jobs using the same label:

runs-on: windows-2025-vs2026

2. Have one job build native MSVC static artifacts using /GL or libraries that require MSVC toolset compatibility.
3. Have a later job restore those artifacts and link them using /LTCG.
4. During the observed run, jobs with the same runs-on: windows-2025-vs2026 label received different image versions (20260510.103.1 and 20260518.113.1), resulting in MSVC toolset mismatch and linker failures:

e.g.

skia.lib(skia.SkGlyph.obj) : error LNK2001: unresolved external symbol __std_minmax_element_f_
skia.lib(skia.SkSLRasterPipelineBuilder.obj) : error LNK2001: unresolved external symbol __std_max_element_2u
skia.lib(skia.SkSLRasterPipelineBuilder.obj) : error LNK2001: unresolved external symbol __std_max_element_1u
skia.lib(skia.SkGradientBaseShader.obj) : error LNK2001: unresolved external symbol __std_max_element_f_
skia.lib(skia.SkGradientBaseShader.obj) : error LNK2001: unresolved external symbol __std_min_element_f_
fatal error LNK1120: 5 unresolved externals

EXEC : fatal error C1900: Il mismatch between 'P1' version '20251208' and 'P2' version '20250730'
LINK : fatal error LNK1257: code generation failed

[chsbuffer]

I understand that runner image updates are rolled out over several days, and this workflow works normally when no rollout is in progress. The problem is specifically that one workflow run can receive multiple image versions for the same runs-on label.

The available workarounds are quite costly: updating Visual Studio at the start of every job is slow and fragile, while merging all version-sensitive jobs into one job would remove most of the parallelism and significantly increase workflow duration.

It would be much better if GitHub Actions could avoid mixing image versions for jobs that use the same runner label within a single workflow run.

[alemuntoni]

This is a different error from the one described by the OP, but:
the MSVC version shipped on image windows-2025-vs2026, version 20260518.113.1 is broken, see here. This is causing failures on lot of builds that use the <=> operator on C++.

Please revert to 20260415.520 until MSVC is fixed.

[pierreluc15]

Please revert to 20260415.520 until MSVC is fixed.

If revert it will revert bug fix of 18.6 #14130 and also revert CPP23 support you can use windows-2022 instead of revert.