Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.
    by camdenclark
  • how does this compare to WillAbides/setup-go-faster?

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

    by y0ssar1an
  • 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.

    by tonymet
  • 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.

    by lukasschwab
  • 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.
    by vbernat
  • Have you considered submitting an upstream patch to the widely used actions/setup-go as well?
    by JyB
  • 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

    by peterldowns
  • 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.

    by wannabe44

Explore Birbla archives

Scaling Golang CI by Replacing actions/setup-go · Birbla