CloudX cut its median Go test job from 131 to 41 seconds

CloudX published a replacement for GitHub's actions/setup-go on 16 September, and says the change cut its own median Go test job from 131 seconds to 41 seconds. The company blames the standard action's cache key, which does not include enough of the job's state, and says the fix stopped 86 percent of redundant test package runs across more than 4,000 commits.

What CloudX found

The standard action builds its cache key from the Go version, the OS and a hash of go.mod and go.sum. CloudX says that is not enough: two parallel jobs on the same commit (a lint job and a test job, for example) both try to save to the same key, and the one that finishes last is the one kept. The next run can load the other job's state, which does not match the work the current job is doing, and Go re-runs test packages it had already run and cached.

What the replacement changes

CloudX's cloudx-io/setup-go action is a direct replacement with the same inputs. It adds a job-specific prefix and the GitHub Actions run_id to the cache key, so parallel jobs no longer overwrite each other and each run saves its own state. The full key CloudX uses is go-cache-${os}-${inputs.cache-key-prefix}-${goVersion}-${ref_name}-${hashFiles('**/go.sum')}-${run_id}. The trade-off is more cache traffic and larger cache blobs, which the post says CloudX offsets with automatic pruning.

The measurement

CloudX quotes two numbers from its own repositories over more than 4,000 commits: a median test job time that dropped from 131 seconds to 41 seconds, and 86 percent of test package executions removed as redundant. The post also warns that saving more often can push a team over GitHub's free cache size, so the faster runs come with storage costs to watch.

Both numbers are CloudX's own, on CloudX's own workloads. A team on a different repository would see a different result, because the gain depends on how often parallel jobs conflict on a given codebase and how much of the test suite is package-cacheable. The replacement needs a one-line change, so a team can measure its own before and after on the same feature branch and read the result in Actions.

The problem the post describes is not new. actions/setup-go has carried a note about parallel-job cache clashes in its issue tracker for a long time, and Go's build cache never prunes itself, which is why a project that never rebuilds keeps growing until a cleanup runs. What is new is a named replacement with the same API, a repository to file bugs against, and two numbers a team can try to reproduce.

Source

• CloudX, Scaling Golang CI by Replacing actions/setup-go, 16 September 2026.