chore: Reduce Windows CI build time

[danskmt]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages are release-note ready, emphasizing what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Reduces Windows CI build time. On main, the Windows build job installs the full toolchain (Node, Maven, Gradle, .NET, Python, Make) plus DigiCert signing tools, even though compiling only needs Node/Python/Make — and its Go module cache uses a Linux-only path that never hits on Windows, so modules re-download every run.
This PR:

• Adds a lean windows-native-build-min deps bundle (Node, Python, Make) with its own small cache for the build job. .NET/Maven/Gradle stay only on the acceptance-test job that needs them.
• Removes the unused DigiCert signing setup from the build job; signing is unchanged on sign windows amd64.
• Fixes the Go module/build cache so it works on Windows (pins GOMODCACHE/GOCACHE to the workspace instead of a Linux-only path).
• Builds the standard and FIPS binaries in one job, drops clean-golang, and adds a verify-fips-artifacts step that fails if the FIPS build did not take effect.

Where should the reviewer start?

• .circleci/config.yml — install-deps-windows-native-build-min, setup-go-build-cache, the build windows amd64 job, and the build-artifact Go cache
• scripts/verify-fips-build.sh and Makefile (verify-fips-artifacts) — the FIPS safety net
• scripts/windows/*.ps1 — skip-if-already-installed logic

How should this be manually tested?

1. Push branch and run test_and_release in CircleCI.
2. Confirm build windows amd64 restores the small build cache (not the ~3.6 GiB one) and does not install .NET/Maven/Gradle/DigiCert.
3. Confirm the verify-fips-artifacts step passes and logs distinct sha256 hashes for the normal vs FIPS binaries.
4. Confirm acceptance-tests windows amd64 still passes (full tool bundle).
5. On a main/release/*e2e* branch, confirm sign windows amd64 and the e2e fips tests (win-server2022-amd64) still pass.
6. Compare Windows build wall-clock/credits against the previous run.

What's the product update that needs to be communicated to CLI users?

None. CI-only change with no user-facing impact.

Risk assessment (Low | Medium | High)?

Low-Medium. CI-only, no user-facing changes. The main correctness concern — removing clean-golang while building normal + FIPS in one job — is guarded by verify-fips-artifacts, which fails the build if the FIPS binary is not distinct from the normal one. FIPS runtime behaviour is still covered by the existing e2e fips tests job.

Any background context you want to provide?

The Windows build was dominated by cache/dependency overhead rather than compilation: a multi-GB tool cache (mostly .NET/Gradle unused by the build), duplicated DigiCert installs, and a Go module cache that never hit on Windows. These changes remove that overhead from the build path while keeping the tools available where they are actually used (tests/signing).

What are the relevant tickets?

CLI-1633

Screenshots (if appropriate)

N/A

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Bypass on Missing Tools 🟡 [minor] If both sha256sum and shasum are missing from the environment, hash_file returns 'NOHASH'. The script then explicitly exits with success (exit 0) at the authoritative gate. This means that in a degraded environment where hashing tools are unavailable, the FIPS integrity check is silently bypassed instead of failing the build. if [ "$normal_hash" = "NOHASH" ]; then echo "[verify-fips] WARNING: no sha256 tool available; skipping byte-difference gate." echo "[verify-fips] Review the build settings above to confirm the FIPS backend." exit 0 fi Loose Version Matching 🟡 [minor] The regex match for the reported Python version (3\.12\.8) lacks a trailing word boundary or end-of-string anchor. If the environment has Python 3.12.81 installed, the check will result in a cache HIT and skip the installation of the specific 3.12.8 version required by the pipeline. if ($reportedVersion -match '3\.12\.8') {

📚 Repository Context Analyzed This review considered 19 relevant code sections from 12 files (average relevance: 0.58) scripts/windows/install-make.ps1 (lines 1-147) scripts/windows/install-node.ps1 (lines 1-78) release-scripts/validate-checksums.sh (lines 1-14) scripts/install_openssl3_fips.sh (lines 1-23) release-scripts/upload-artifacts.sh (lines 1-199) CONTRIBUTING.md (3 segments, lines 407-550) CLAUDE.md (2 segments, lines 1-116) ... and 5 more file(s)

🤖 Repository instructions applied (from AGENTS.md)