I always advocate having custom-built docker images for CI, periodically refreshed for security fixes. CI should not run more than few seconds over the standard time to run the same thing from a dev machine.

However, other people around me are fine with apt installs and pip installs from global mirrors in every CI run. So I may be just autistic.

Hey everyone, one of the authors here. This is a "small" improvement that has saved us a LOT of developer time over the last few months. It's actually quite crazy to me that the default actions/setup-go simply does not work well if you want to have more than one golang action running at the same time.

The blogpost has a lot of technical details, but you can also just read the code and try it yourself:

https://github.com/cloudx-io/setup-go

Have you considered submitting an upstream patch to the widely used actions/setup-go as well?

I am setting cache to `false` and directly use actions/cache:

    - uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
      if: ${{ inputs.setup-go == 'true' }}
      with:
        path: |
          ${{ env.gocache }}
          ${{ env.gomodcache }}
        key: ${{ runner.os }}-${{ runner.arch }}-go${{ steps.go-setup.outputs.go-version }}-${{ hashFiles('go.sum') }}-${{ env.today }}
        restore-keys: |
          ${{ runner.os }}-${{ runner.arch }}-go${{ steps.go-setup.outputs.go-version }}-${{ hashFiles('go.sum') }}-
          ${{ runner.os }}-${{ runner.arch }}-go${{ steps.go-setup.outputs.go-version }}-

You get one new cache every day, and you can still load the most recent one if you are the first run today.

There are some good off-cuts that didn't make the official post, but which might be of interest to HN!

It only gets a brief mention, but the cache-pruning change was an interesting one. Cache accretion happens in the default actions/setup-go too, but dramatically increasing the number of cache-writes for cloudx-io/setup-go made it an actual issue.

As the cache grows, so does the time it takes to load it from GitHub's actions cache... and that grows until it's a significant time-suck in CI. We prune with basic mark-and-sweep.

Digging deeper, the pluggable `GOCACHEPROG` (introduced in Go 1.24) is a really useful tool. Shimming the normal cache logic for measurement, for example. In theory this should also be attractive for remote caching.

CI is expensive, and often a blocker for critical releases (e.g. patching a production issue). Every second saved is a relief.

I’ve long wondered why setup-go was so slow and expensive it’s great to see improvements made.

how does this compare to WillAbides/setup-go-faster?

https://github.com/WillAbides/setup-go-faster

Separate but if you run CI at any scale you should have an agent working to improve CI constantly and alert you to any regressions / flakiness. It's something that agents can do in the background and open PRs for your team.

I'm working on something that removes CI completely and lets your agents certify their own tests. It is pretty rough right now but I'd love feedback -- pushgate.dev