ci(windows): run the tier-1 unit tests weekly on windows-latest

[catincloudlabs]

What this changes

Part 4 of #487, decision (c) from the offer there, as the second pull request it named: a weekly Windows run of the tier-1 unit tests. #526 fixed causes 1 to 6; with this, every part of the issue's ask has a change behind it, and closing it is yours.

One new file, .github/workflows/windows.yml. It runs uv run pytest -q on windows-latest, every Monday at 06:40 UTC and on workflow_dispatch, with the same connector-extra sync ci.yml's tests job uses, so a test that would importorskip for want of a client library runs here the same as it does there. Pinned action SHAs are the ones ci.yml already uses. Nothing about the engine or the tests changes.

Decisions worth your attention

• Weekly, not per pull request, and not a required check. The issue's own reasoning: Windows is not a claimed platform, the suite took just under eighteen minutes on a Windows workstation with every extra installed, and a Windows leg on every pull request would make Windows-only flakiness a merge blocker. The cron is off the hour, as repo-stats.yml's is.
• One Python version, 3.12, rather than the tests job's three. The run exists to catch platform defects, which do not vary by interpreter, and 3.12 is the version the issue's Windows measurements were taken on. Three runs a week would triple the cost of finding each defect once.
• timeout-minutes: 90. A hosted runner is slower than a workstation; the bound is there so a hung test fails the run instead of holding a runner for the six-hour default.
• The symlink tests take the skip from decision (a), so the job needs no Developer Mode. The fixture probes the privilege and skips with a reason where the OS refuses the link.
• Checkout with LF. Git for Windows defaults to core.autocrlf=true and actions/checkout does not override it, so the first dispatched run read the bundled Ossie schema's sha256 as bea4565d… against the recorded 27aab111…, which is exactly the hash of the LF file with CRLF newlines. The job now sets core.autocrlf false before checkout and tests what the wheel ships. Whether the repository wants a .gitattributes so a default Windows clone matches too is on The dex-core test suite fails on Windows, and CI has no Windows job #487.
• The one failure seen once and not reproduced on the issue, test_build_evidence.py::test_a_run_that_built_the_required_nodes_is_validated, is the kind of thing a weekly run will either confirm or never see again. If it flakes here, that is a finding, not a reason to loosen the run.

Shown running

A workflow can only be exercised by a runner, so this one was dispatched on the fork before the pull request was opened, from this branch, on windows-latest:

https://github.com/catincloudlabs/dex/actions/runs/38185553066

Both runs, before and after the checkout fix, are in the first comment below. The fork's main was fast-forwarded to this branch only so GitHub would register the workflow for dispatch; nothing else is on it.

Files

• .github/workflows/windows.yml: the workflow, with its reasoning in the header comment, and a git config --global core.autocrlf false step before checkout (see the decision above).
• CHANGELOG.md: one Added entry under Unreleased.

🤖 Generated with Claude Code

[catincloudlabs]

Two dispatched runs of this workflow on the fork, both on windows-latest, both from this branch on main at cfbdd37.

Run 1, the workflow as first opened (38185553066):

5 failed, 4448 passed, 149 skipped in 1086.65s (0:18:06)

Run 2, after the core.autocrlf false step (38187030362):

3 failed, 4450 passed, 149 skipped in 1087.32s (0:18:07)

The two that moved are the three tests pinning the bundled Ossie schema's hash (tests/ossie/test_corpus.py, tests/ossie/test_loader.py, tests/test_packaging.py): Git for Windows checks text files out with CRLF by default, the hash is of bytes, and the sha256 of the LF file with its newlines replaced by CRLF is exactly what run 1 read. The step is the fix on the job's side, so it tests what the wheel ships; whether the repository wants a .gitattributes so a default Windows clone matches too is on #487.

The three that remain are not this workflow's to fix, and both are reported on #487 with reproductions:

• tests/test_skill_wrapper.py::test_both_ways_into_uv_carry_the_child_env, both parametrizations: the test sets os.name to "posix", so pathlib builds a PosixPath on Windows. It arrived in Credentials and privileges reach only: CI secrets, the skill wrapper, dogfood containers, profile and key modes #530, after every Windows run on the issue, and it is the class fix(windows): use forward slashes in dex demo's output so the suite passes on windows #526 fixed in the spine's wrapper test.
• tests/transform/test_build_evidence.py::test_a_run_that_built_the_required_nodes_is_validated: stale_artifacts=True, so the outcome is STALE where the test expects VALIDATED. This is the one the issue's offer listed as seen once and not reproduced; the hosted runner reproduced it on its second run, while the workstation passed it five times out of five. An intermittent that depends on file timestamps written within the same tick is what that pattern looks like, and it is now a finding rather than a footnote.

So the first weekly run on main will be red by those three until they are fixed, which is the job doing what it is for. Runtime on the hosted runner is eighteen minutes, in line with the workstation; the timeout-minutes: 90 is generous by design.