Revived the Windows workflows, which had reached no runner since 2025

[fdesbiens]

The problem

The four GUIX Studio workflows requested runs-on: windows-2019, an image GitHub retired on 2025-06-30. Nothing can match a retired label, so every run queued for the full 24 hours and was then cancelled without ever starting a job:

run 28477318708  created   2026-06-30T21:33:40Z
                 cancelled 2026-07-01T21:33:41Z     <- exactly +24h, never executed

Every run of these workflows since 2025-09-29 has that same created-plus-24h-cancelled shape. The Studio demo, demo compile, view and MSIX package workflows have gated nothing for about a year. A manual workflow_dispatch on 2026-08-25 queued the same way.

Three more defects sat behind that one, so fixing the image alone would not have produced a green run — and once the workflows reached a runner they immediately surfaced two more that had been accumulating unseen.

Verified result

Every change here was confirmed on a real windows-2022 runner before this PR was opened, not reasoned about:

Workflow	Result	Tests	Time
GUIX Studio Demo Test	✅ success	227 / 227	184 s
GUIX Studio Demo Compile Test	✅ success	212 / 212	143 s
GUIX Studio View Test	⚠️ runs fully	1097 pass / 32 fail	~80 min

Runners are assigned in seconds now, against 24 hours of queueing before.

What is fixed

1. Runner image and action pinning

windows-2019 to windows-2022, pinned rather than windows-latest on the same reasoning eclipse-threadx/threadx applies to ubuntu-24.04: which image the build ran on should be a reviewable commit, not something that changes underneath it.

Every action reference is now a 40-character commit SHA with the version in a trailing comment, following the pattern threadx adopted in #660. Versions moved with the pinning:

Action	Was	Now
actions/checkout	v4 (unpinned)	v7.0.1
actions/upload-artifact	v3.1.3	v7.0.1
EnricoMi/publish-unit-test-result-action	v2	v2.24.0

upload-artifact@v3.1.3 mattered on its own: GitHub began auto-failing every request that used v3 on 2025-01-30, and both upload steps run under if: success() || failure(), so every run would have ended red even with the tests passing.

Compatibility was checked against each new action.yml rather than assumed, for every input these workflows actually pass — checkout keeps submodules; upload-artifact keeps name and path, and the one upload per run means the v4 rule against uploading a name twice does not bite; the publish action keeps check_name and files, and the composite variant still exists at v2.24.0, which is the one a Windows runner needs. All three tags were confirmed to resolve to the SHAs pinned here, and all three are the current latest.

2. Visual Studio discovery

The scripts hard-coded a VS edition path. build_guix.cmd, test_studio_demo.cmd, test_studio_demo_compile.cmd and test_studio_view.cmd all called VS 2022 Enterprise, which no developer machine has; build_guix_studio.cmd called VS 2022 Community, which no GitHub runner has. So the demo test's build step would have failed on its first line.

All five now locate the installation with vswhere — matching what build_guix_studio_msix_package.cmd already did — and check the result instead of assuming the call succeeded. Verified against a Community install, where the Enterprise path does not exist.

Also removed the dead Program Files/Python36 PATH lines. No supported runner image has shipped that Python for years, python is already on PATH there, and the lines embedded literal quote characters into PATH.

3. IMAGE_INFO collided with the Windows SDK

With the workflows reaching a runner again, the Studio build failed immediately:

guix_studio/system_pngs.h(15,8):                          error C2011: 'IMAGE_INFO': 'struct' type redefinition
Windows Kits/10/Include/10.0.26100.0/um/Filter.h(340,16): error C2011: 'IMAGE_INFO': 'struct' type redefinition

plus eight C2027 errors following from it. GUIX Studio declared its own two-field IMAGE_INFO in the global namespace; a newer Windows SDK added a struct of the same name to um/Filter.h, which arrives through the Windows headers the MFC sources already include. SDK 10.0.22621.0 does not define it; 10.0.26100.0 does.

This was latent, not new, and the reason it hid is worth recording: studiox.vcxproj sets <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>, the MSBuild wildcard for "newest installed SDK". So which SDK compiles the Studio depends entirely on the machine — a box whose newest is 22621 builds, the runner image carrying 26100 does not. Any developer who installed a current SDK would have hit this.

Renamed the Studio type to STUDIO_IMAGE_INFO, 13 references across five files. It is private to the Studio, so nothing outside guix_studio sees the name.

Also dropped the -winsdk=10.0.22621.0 argument build_guix_studio.cmd passed to VsDevCmd. It never had the effect it looks like it has — the wildcard in the project file governs the SDK the compile actually uses, so the argument only set the shell environment while MSBuild picked the newest SDK anyway. Keeping it would suggest the build is pinned to an SDK when it is not.

4. Two stale paths from a February 2025 search-and-replace

522aafcc ("Updated scripts for VS Community 2022") moved three paths in test_demo/test_main.py from vs_2019 to vs_2022. Two were right: guix_studio/build/vs_2019 really had been renamed. The third was collateral damage — ports/win32/build/vs_2019 was never renamed, and still holds the only guix.vcxproj and guix.sln in the repository. So --build_guix has raised this for eighteen months, before compiling a single library configuration:

Exception: guix.sln not found. path=../../../ports/win32/build/vs_2022/guix.vcxproj

The same commit then made the opposite error: it never touched test_view/ at all, where three references still named the old Studio directory (test_main.py, test_utils.py, test_string_import_export.py). That suite could not locate the Studio to launch it:

MSBUILD : error MSB1009: Project file does not exist.
Switch: ../../../guix_studio/build/vs_2019/studiox.sln
Exception: Unable to locate Studio executable.

Both fixed. Verified by building the library locally — guix.vcxproj is Win32-only, still on PlatformToolset v142, and produces Debug/gx.lib.

5. Dependabot

A SHA pin with nothing moving it is worse than a floating tag: it holds CI on whatever was current the day it was written. This repository is the case study — nothing had ever reported that an action moved, so upload-artifact sat four majors behind on a version GitHub auto-fails.

.github/dependabot.yml follows the configuration threadx added in #662, with three differences specific to this repository and documented in the file: only three distinct actions are in use; there is no .github/CODEOWNERS here for reviewer routing; and the dependencies label does not exist yet, so Dependabot creates it on the first pull request.

target-branch: dev, so this arms on merge without firing — nothing happens until a release merge carries the file to master. That also opts out of Dependabot security updates, which only run against the default branch; for this ecosystem an action advisory arrives as an ordinary weekly bump, but it is a real trade and stated in the file rather than left to be rediscovered.

Trigger branches — scoped to evidence, not applied uniformly

The demo and demo compile workflows now also run on dev. They previously fired on master only, so they gated no pull request that anybody opened — the same defect threadx fixed in #652. Switched on only after both suites were verified green on a runner.

The other three are deliberately left alone, each for its own reason:

• regression_test.yml does reach a runner, and is red. Its last real run (2026-06-30) was 5 failures out of 732: guix_all_widgets_accordion_menu, guix_ml_text_view_32bpp, guix_all_widgets_16bpp_canvas_animation (SEGFAULT), guix_animation_complete, guix_animation_complete_push_stack. Adding dev here would make every pull request red on a suite broken since June. It needs fixing first, and that is separate work.
• studio_view_test.yml can find the Studio again and now runs its full GUI suite on a hosted runner — a useful discovery in itself — but it reports 32 failures out of 1129, spread across about nineteen sub-suites. Enabling gating on that is the wall of red this PR exists to avoid.
• studio_msix_package.yml is workflow_dispatch only by design. It packages a release rather than testing a change, so there is nothing to gate. Its upload path was corrected from build/vs_2019/... to build/vs_2022/..., where build_guix_studio_msix_package.cmd actually builds; that artifact was always empty.

Scope note

This began as "bump a runner label" and became six commits. That is a consequence of the defect rather than scope creep: a year with no CI let three real bugs accumulate silently, and each had to be fixed before the next became visible. The two suites that now pass are the evidence that the sequence terminates.

Not fixed here, and worth tracking separately: the 5 regression-suite failures, the 32 view-test failures, and the absence of a CODEOWNERS file.