Commit Graph

6 Commits

Author SHA1 Message Date
enricobuehler 3a3c353a5e ci(windows): set CARGO_TARGET_DIR=C:\t — dodge MAX_PATH in CMake-from-source builds
With the BOM fixed (shell: pwsh), the build got far enough to compile audiopus_sys, which
does a CMake-from-source build of libopus. The runner's host workdir sits deep under
C:\Windows\System32\config\systemprofile\.cache\act\<hash>\hostexecutor\, so target\debug\build\
audiopus_sys-*\out\build\CMakeFiles\CMakeScratch\TryCompile-*\...\.tlog overran Windows' 260-char
MAX_PATH and MSBuild's tracker failed to create its .tlog (DirectoryNotFoundException -> MSB6003,
"CL.exe konnte nicht ausgeführt werden"). Pointing CARGO_TARGET_DIR at C:\t shortens every nested
build path well under the limit (fixes audiopus_sys + SDL3, both CMake-from-source).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 08:18:34 +00:00
enricobuehler 9c6c5ba0bb ci(windows): use shell: pwsh (PowerShell 7) — fixes GITHUB_ENV BOM corruption
Windows PowerShell 5.1's Out-File -Encoding utf8 prepends a UTF-8 BOM, corrupting the first
GITHUB_ENV line so CARGO_WORKSPACE_DIR silently never got set -> windows-reactor build.rs panic
-> CI build failed (runs 8765/8768). pwsh 7 writes UTF-8 without a BOM. Installed PowerShell 7.6.2
MSI on the runner and put C:\Program Files\PowerShell\7 on the daemon wrapper PATH so jobs find
pwsh; switched all windows.yml steps to shell: pwsh. (Reproduced locally with CARGO_WORKSPACE_DIR
set: the build is green in 2m37s — the BOM was the only issue.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 08:10:30 +00:00
enricobuehler f7a3a9fb10 ci(windows): restore paths filter + document global runner scope
Re-add the paths filter (the trigger was never the problem — the runner was registered at the
wrong scope, so org-repo runs found 'no fitting runner' despite the runner showing idle). Document
in setup-windows-runner.ps1 that the registration token must be GLOBAL (Site Administration ->
Actions -> Runners), like the Linux runner. CARGO_WORKSPACE_DIR is set via GITHUB_ENV in a step
(the job-env ${{ github.workspace }} form didn't resolve, leaving it unset -> reactor build.rs
panic).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 07:38:08 +00:00
enricobuehler c758e19f74 ci(windows): set CARGO_WORKSPACE_DIR via GITHUB_ENV (not job-env expression)
Mirror apple.yml's shape — drop the job-level env + defaults blocks; set CARGO_WORKSPACE_DIR
from $GITHUB_WORKSPACE in a step (Gitea can't resolve github.workspace at job-env-eval time)
and use per-step shell: powershell.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 07:24:53 +00:00
enricobuehler 005b28cb0b ci(windows): drop paths filter (trigger reliability) + NO_COLOR runner logs
The paths filter wasn't dispatching the run on the newly-added workflow (the runner is healthy
and 'declare successfully', but received no task). Match apple.yml: trigger on every push to main
+ PRs. Also set NO_COLOR in the daemon wrapper so runner.log is plain text (the ANSI spinner
garbled it).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 07:16:26 +00:00
enricobuehler 526aa84499 ci(windows): build/clippy/fmt/test workflow on the self-hosted Windows runner
runs-on: windows-amd64 (home-windows-1, host mode). Build + clippy(-D warnings) + fmt + test the
WinUI 3 client. The toolchain is baked into the runner's daemon env; the workflow only sets
CARGO_WORKSPACE_DIR=${{ github.workspace }} (windows-reactor's build.rs needs it). Triggers on
changes to the windows crate / core / Cargo / this workflow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 07:11:11 +00:00