ci(vcpkg): disable compiler tracking for x64-windows host triplet

[bobtista]

• Follow up for ci(vcpkg): Fix recurring binary cache invalidation from runner image updates #2371

The binary cache introduced in #2371 disabled compiler tracking for the x86-windows target triplet, but not for the x64-windows host triplet. vcpkg builds host tools (vcpkg-cmake, vcpkg-cmake-get-vars, vcpkg-tool-meson, pkgconf) against the host triplet, and their ABI hashes propagate transitively into every target package hash — including ffmpeg:x86-windows and zlib:x86-windows.

When the runner image updated from 20260301.50.1 to 20260317.73.1, the full Visual Studio version changed from 17.14.37012.4 to 17.14.37111.16 (even though VCToolsVersion stayed at 14.44.35207). This was enough to shift every x64-windows ABI hash, which cascaded into all x86-windows package hashes. The GHA cache key (which only hashes the triplet files) still matched the old entry, so GHA reported a hit and restored the 55 MB archive — but vcpkg found zero matching packages inside it and rebuilt ffmpeg from source (~17 min) on every run.

This also triggered a doom loop: the save step is gated on cache-hit != 'true', so the freshly rebuilt binaries were never saved, and every subsequent run also rebuilt from scratch.

Adding triplets/x64-windows.cmake with VCPKG_DISABLE_COMPILER_TRACKING fixes both issues:

• Host tool ABI hashes become stable across VS updates
• Adding the new file changes hashFiles('triplets/*.cmake'), so the GHA key automatically gets a new hash, the first run is a clean miss, the cache saves correctly, and all subsequent runs hit

Test plan

• First CI run after merge will cache-miss (new triplet hash), rebuild ffmpeg once, and save
• Subsequent CI runs restore all packages and skip the ffmpeg rebuild

[greptile-apps]

Greptile Summary

This PR adds a custom triplets/x64-windows.cmake overlay to stabilise vcpkg's host-tool ABI hashes across Visual Studio minor-version updates on GitHub-hosted runners, completing the work started in #2371 which only covered the x86-windows target triplet.

• The new file mirrors triplets/x86-windows.cmake exactly, adding VCPKG_DISABLE_COMPILER_TRACKING ON to the standard x64-windows settings (dynamic CRT/library linkage). This is the correct place to do it: VCPKG_OVERLAY_TRIPLETS in build-toolchain.yml already points at the triplets/ directory, so vcpkg will pick up the override automatically.
• Because the GHA cache key is hashFiles('triplets/*.cmake'), adding the new file immediately invalidates the old (corrupt) cache entry. The first post-merge run will be a clean miss, rebuild ffmpeg once, and save correctly; all subsequent runs will restore from cache.
• The save gate (cache-hit != 'true' on the win32-vcpkg-debug / Generals job) is unaffected and will now work as intended once the cache is primed with the new key.
• No functional code was changed; risk is limited to the one-time cold cache run that is by design.

Confidence Score: 5/5

Safe to merge — single new CMake triplet file with correct settings, no functional code changes.

The change is a one-line addition (VCPKG_DISABLE_COMPILER_TRACKING ON) inside a new overlay triplet file that mirrors the already-proven x86-windows.cmake pattern. The CI wiring (overlay path, cache key hashing) is already in place and handles the new file correctly. No P0/P1 findings.

No files require special attention.

Important Files Changed

Filename	Overview
triplets/x64-windows.cmake	New host-triplet override that mirrors x86-windows.cmake and adds VCPKG_DISABLE_COMPILER_TRACKING ON to stabilise host-tool ABI hashes; content and intent are correct.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Runner image updates VS version] -->|Old behaviour| B[x64-windows ABI hash changes]
    B --> C[All x86-windows package hashes shift]
    C --> D[GHA cache key still matches old entry]
    D --> E[GHA reports hit, restores stale archive]
    E --> F[vcpkg finds 0 matching packages]
    F --> G[ffmpeg rebuilt from source ~17 min]
    G --> H{cache-hit == true?}
    H -->|Yes - doom loop| I[Save step skipped, next run rebuilds too]
    A -->|New behaviour with this PR| J[x64-windows.cmake sets VCPKG_DISABLE_COMPILER_TRACKING ON]
    J --> K[Host-tool ABI hashes stable across VS updates]
    K --> L[hashFiles triplets/*.cmake produces new key]
    L --> M[First run: clean cache miss]
    M --> N[ffmpeg rebuilt once, cache saved]
    N --> O[All subsequent runs restore full cache]

Loading

_{Reviews (1): Last reviewed commit: "ci(vcpkg): Disable compiler tracking for..." | Re-trigger Greptile}

[xezon]

My understanding of this is that we keep doing AI prompts in the hope that the AI fixes the problem. But so far nothing has worked. Can we try to properly understand the root issue and then make a proper fix that avoid the issue forever, instead of applying one AI patch after another in the hopes that it solves the problem?

[bobtista]

My understanding of this is that we keep doing AI prompts in the hope that the AI fixes the problem. But so far nothing has worked. Can we try to properly understand the root issue and then make a proper fix that avoid the issue forever, instead of applying one AI patch after another in the hopes that it solves the problem?

Fair - we're probably just iterating down the wrong path. It seems that NuGet is worth looking into, it's recommended in the results when I google for vcpkg and github ci

[bobtista]

closing in favor of a nuget approach in #2542