Skip to content

ci: run the Windows leg on the fleet's Windows VM - #4

Open
zignd wants to merge 24 commits into
developfrom
ci/windows-vm
Open

zignd wants to merge 24 commits into
developfrom
ci/windows-vm

Conversation

@zignd

@zignd zignd commented Nov 7, 2026

Copy link
Copy Markdown
Collaborator

The self-hosted matrix left Windows out because there was no Windows machine. The fleet now has one: a Windows Server 2022 VM on the Linux server, registered as an ephemeral runner with self-hosted, Windows, X64.

The leg keeps its hosted fallback, so unsetting TRACE_CI_RUNNERS still gives the four hosted legs.

zignd added 24 commits November 7, 2026 01:21
The self-hosted matrix left Windows out because there was no Windows machine. The fleet now has one: a
Windows Server 2022 VM on the Linux server, registered as an ephemeral runner with the Windows labels.
The leg keeps its hosted fallback, so unsetting TRACE_CI_RUNNERS still gives the four hosted legs.
The hosted image ships the v145 platform toolset; the fleet's Windows VM has VS 2022 Build Tools, which
is v143. The hosted legs keep v145.
The content pipeline target asks vswhere for MSBuild without -products *, and vswhere's default product
filter skips the standalone Build Tools. On the fleet's Windows VM that returned an empty path and the
build ran an empty command; the hosted image has full Visual Studio, so it never showed there.
Cake's VSWhereLatest uses vswhere's default product filter, which skips the standalone Build Tools, so
the content pipeline's library check dereferenced a null path on the fleet's Windows VM. Products = "*"
finds it; the hosted image has full Visual Studio and is unaffected.
The VS templates project needs the full Visual Studio IDE (VSSDK1077: no extensions directory), which the
fleet's Windows VM does not have: it carries the Build Tools, which is what the framework, the tools and
the content pipeline need. The workflow sets MONOGAME_SKIP_VS_TEMPLATES for the self-hosted Windows leg;
the hosted legs keep building the extension.
…e layout

The parser stores each directory relative to the working directory. On the hosted runners the workspace is
on D: and C:/This/Does/Not/Exist cannot be relativized, so the path stays absolute and the old assertion
passed; on the fleet's Windows VM the workspace is on C: and the parser produces a relative path. The
test now asserts what the parser promises.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant