CI: Go module VCS cache race when Boost sets GOPROXY=direct

[yahav-ohana]

Reporter

Assaf Attias

Impact

PR CI in jfrog/jfrog-cli-security has started failing intermittently in the Pretest go vet step over the last 1-2 days when Boost is enabled in the workflow.

Evidence

• Failing PR CI job: https://github.com/jfrog/jfrog-cli-security/actions/runs/26884137529/job/79291615878?pr=723
• Assaf tested a workflow option that disables Boost, and the same flow passed without Boost enabled.
• The failure appears only on PR CI, not on Assaf's fork/branch action run.

Current theory

The failure does not look PR-code-specific. The module version jfrog-cli-artifactory@v0.8.1-0.20260603105750-3886c0f01286 is valid and available on proxy.golang.org.

The suspected issue is that jfrog/boost@v0 runs before go vet and forces GOPROXY=direct. That makes Go use direct VCS fetches, including shallow/unshallow git fetches. Concurrent Go module fetches can then race in the module VCS cache and fail with errors such as:

fatal: shallow file has changed since we read it

Expected behavior

Boost should not make downstream Go CI less reliable. Workflows that run Boost before go vet / go test should avoid introducing direct VCS cache races.

Possible fix direction

Prefer the Go module proxy instead of forcing GOPROXY=direct, and consider pre-downloading modules before go vet / go test if needed.