[chiliec]

windows-release.yml caches Boost and OpenSSL but compiles vizd itself from scratch on every push to master. Build vizd is ~18 of the ~24 min job (last three master runs: 23–24 min).

Change (.github/workflows/windows-release.yml only):

• install mingw-w64-ucrt-x86_64-ccache and set it as CMake's C/CXX compiler launcher;
• CCACHE_DIR under RUNNER_TEMP (outside the workspace), saved per commit (windows-ccache-mingw-ucrt64-<sha>) and restored from the newest prefix match, CCACHE_MAXSIZE=1G;
• CCACHE_COMPILERCHECK=content: setup-msys2 reinstalls GCC on every run, which changes its mtime, and the default mtime check would make every lookup a miss;
• ccache -z before the build and ccache -s after, so the log shows this run's hit rate.

Build flags, targets, the bundle and the release step are unchanged.

Testing: this workflow doesn't run on PRs. It runs on pushes to master and windows_build, and only master publishes a release. I fast-forwarded windows_build (untouched since #116, 505 commits behind) to this commit, so it gets a real Windows run that builds everything but publishes nothing. I'll run it twice, cold and then warm, and post both timings and the ccache -s output here.

[chiliec]

Two real runs on windows_build (same commit, nothing published):

	cold (no cache)	warm (rerun)
Build vizd	21m09s	26s
Build cli_wallet	2m46s	1m34s
ccache hits	0 / 177	176 / 177
whole job	~27 min	~5 min

Cold is a bit slower than the usual ~18 min because every TU also goes through ccache once. The cache entry is 34 MB. The warm number is the best case (same commit); a real master push with a few changed files lands in between.

[On1x]

Measured the effect on the same commit (621fc409), comparing the two attempts of the windows_build run 41012243279:

attempt	job	duration
1 (cold — cache saved at the end)	Build vizd (MSYS2/MinGW UCRT64)	06:07:32Z → 06:34:44Z = 27m12s
2 (warm — restored windows-ccache-mingw-ucrt64-621fc409…)	same	06:39:04Z → 06:44:16Z = 5m12s

That is a 5.2× speedup, and it is not an artefact of a skipped build: the log shows 171 Building CXX object lines and ccache reported Hits: 176 / 177 (99.44%), Uncacheable calls: 79 / 256 — the compile ran, it was just served from cache.

For comparison, the four most recent master runs without ccache took 24m29s, 23m52s, 22m27s and 24m15s — so the cold run here is in the same band (plus the one-off cache save) and the warm run is ~4.5× faster than today's master.

One thing worth pairing with #206: the saved ccache entry is 32 MiB per commit-key (refs/heads/windows_build, key windows-ccache-mingw-ucrt64-<sha>), and it lives in the 10 GiB Actions cache quota for 7 days. At the current rate of windows-release runs that is roughly 1.5–2 GiB of steady-state quota on its own, so the per-PR cleanup from #206 stops being a nice-to-have once this lands.

No objection from me on the substance — the key/restore-key pair is correct (per-commit key, prefix restore, CCACHE_COMPILERCHECK=content is the right call with a reinstalled MSYS2 toolchain).

[On1x]

Checked the same-commit measurement in the thread: Build vizd went 21m09s cold → 26s warm on 621fc409, with ccache hit numbers printed by the run itself. CCACHE_COMPILERCHECK=content is the right choice given setup-msys2 reinstalls the toolchain every run, and CCACHE_DIR outside the workspace keeps the checkout clean. Build flags, targets, bundle and release step are unchanged; the workflow only publishes on master.