ci: stop re-downloading CMake/Ninja on every Windows run

lukka/get-cmake@latest re-fetched and re-extracted CMake + Ninja on
every single Windows CI run. Its own cache (routed through this
act_runner's built-in cache server) reported "Cloud cache miss" on
every run, even one immediately after a run that logged a successful
save under the exact same key -- an incompatibility between its
bundled cache client and this act_runner's cache-server implementation,
not a config gap. Separately and more importantly: the archive
extraction step alone measured ~7.5 minutes for a 45MB zip on this VM,
consistent with Defender real-time scanning rather than raw disk I/O.
Together this was the dominant cost of every Windows CI run.

CMake 4.4.2 and Ninja 1.12.1 are now installed once, directly on the
winvm-builder VM's system PATH (C:\BuildTools\cmake, C:\BuildTools\
ninja), sidestepping the third-party action's cache entirely rather
than debugging its internals further. Both Windows jobs now just
verify cmake/ninja are present and fail loudly if not, instead of
silently falling back to a slow reinstall. Full detail, including how
to redo this if the VM is ever rebuilt, is in README's new "Windows
runner: persistent build tools" section -- this is VM state, not
something git reproduces.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE

.gitea/workflows/build.yml

@@ -127,11 +127,29 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
 
-      - name: Install build dependencies
+      - name: Verify build dependencies
         # winvm-builder is a self-hosted act_runner labeled "windows-latest";
         # it is NOT the GitHub-hosted image, so none of that image's
-        # preinstalled tooling (cmake included) can be assumed present.
+        # preinstalled tooling can be assumed present. This used to be
-        uses: lukka/get-cmake@latest
+        # `uses: lukka/get-cmake@latest`, which re-downloaded and
+        # re-extracted CMake + Ninja on every single run -- its own cache
+        # (routed through this act_runner's cache server) reported a "cloud
+        # cache miss" on every run even immediately after a successful save,
+        # and separately the extraction step alone measured ~7.5 minutes on
+        # this VM (consistent with Defender real-time scanning, not raw I/O)
+        # -- together the dominant cost of every Windows CI run. CMake and
+        # Ninja are now installed once, directly on winvm-builder's system
+        # PATH (C:\BuildTools\cmake\bin, C:\BuildTools\ninja -- see the
+        # README's "Windows runner: persistent build tools" section for
+        # exactly what that machine has installed and how to redo it if the
+        # VM is ever rebuilt). This step just fails loudly if that ever
+        # stops being true, rather than silently falling back to a slow
+        # re-download.
+        shell: powershell
+        run: |
+          $ErrorActionPreference = "Stop"
+          cmake --version
+          ninja --version
 
       - name: Cache OBS SDK bootstrap deps
         # See the matching step in the macOS job above for why this is

.gitea/workflows/release.yml

@@ -144,8 +144,16 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
 
-      - name: Install build dependencies
+      - name: Verify build dependencies
-        uses: lukka/get-cmake@latest
+        # See build.yml's Windows job for why this is no longer
+        # lukka/get-cmake@latest -- CMake and Ninja are installed once,
+        # directly on winvm-builder's system PATH; this just fails loudly
+        # if that ever stops being true.
+        shell: powershell
+        run: |
+          $ErrorActionPreference = "Stop"
+          cmake --version
+          ninja --version
 
       - name: Configure, build, test, verify
         # Windows PowerShell (powershell.exe), not PowerShell Core (pwsh) --

README.md

@@ -281,6 +281,51 @@ and a permanently red CI teaches people to ignore CI. **Do not remove the
 warning:** a green job that quietly stopped building the plugin is worse than
 a red one.
 
+### Windows runner: persistent build tools (2026-09-07)
+
+`winvm-builder`'s Windows job used to install its own CMake + Ninja on every
+single run via `uses: lukka/get-cmake@latest`. That action has its own
+caching (routed through this act_runner's built-in cache server, the same
+mechanism `.deps/`'s `actions/cache` step above relies on and that one does
+work) but it never hit: every run logged `Cloud cache miss` against the same
+cache key, even immediately after a run that logged a successful save under
+that exact key -- some incompatibility between `lukka/get-cmake`'s bundled
+cache client and this act_runner's cache-server implementation, not
+"caching isn't configured." Separately, and the larger cost: the archive
+extraction step alone measured **~7.5 minutes** for a 45MB zip on this VM
+(13:11:14 to 13:18:48 in one captured run) -- consistent with Windows
+Defender real-time-scanning every extracted file, not raw disk I/O, though
+that specific cause is not confirmed. Together this was the dominant cost of
+every Windows CI run, cold cache or not.
+
+Fix: CMake 4.4.2 and Ninja 1.12.1 are now installed once, directly on the
+`winvm-builder` VM (Proxmox VMID 110, host pve4/192.168.1.145), not fetched
+per-run:
+
+- `C:\BuildTools\cmake\` (from
+  `cmake-4.4.2-windows-x86_64.zip`, Kitware's GitHub releases) and
+  `C:\BuildTools\ninja\` (from `ninja-win.zip`, `ninja-build/ninja` v1.12.1
+  release) — plain `Expand-Archive` drops, nothing installed via an
+  installer/MSI.
+- Both added to the **Machine**-level `PATH`
+  (`[Environment]::SetEnvironmentVariable('PATH', ..., 'Machine')`, not
+  `setx`, which silently truncates a `PATH` this long).
+- The `GiteaRunner-winvm-builder` scheduled task (`C:\gitea-runner\
+  gitea-runner.exe daemon`, runs as SYSTEM) was stopped and restarted after
+  the `PATH` change — a already-running process does not pick up an updated
+  Machine environment variable, only processes started after the change do,
+  and every CI job is a child process of this one long-running daemon.
+
+Both workflows' Windows jobs now just run `cmake --version` / `ninja
+--version` as a "Verify build dependencies" step and fail loudly if either
+is missing, instead of silently falling back to the slow per-run install.
+
+**This is VM state, not something `git clone` reproduces.** If
+`winvm-builder` is ever rebuilt or reimaged, redo the three steps above
+(download+extract both zips under `C:\BuildTools\`, extend the Machine
+`PATH`, restart the scheduled task) before expecting Windows CI to pass
+again — there is nothing in this repo that does it automatically.
+
 ### Where the macOS bootstrap actually got to
 
 Six CI iterations, each fixing a real failure visible in the logs: