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.
Scaling Golang CI by Replacing actions/setup-go
21–25 of 25 posts
Re: Scaling Golang CI by Replacing actions/setup-go
#22I'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
One thing to consider — one of the reasons I want our Actions CI to be fast is that I do a good deal of agentic coding work in parallel (worktrees) on very, very small VMs, but we have some computationally demanding tests and linters. Delegating the expensive validation work to a separate environment — the beefier Actions runner, with run-isolation — and then watching the check status actually tightens the feedback loop for these agents.
Like with all things CI, your mileage will vary according to where you write your code and what the code does.
Re: Scaling Golang CI by Replacing actions/setup-go
#23I 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.
Yeah, that drives me bonkers. Just set up a separate CI/CD for the images themselves that update daily as needed.
We set up a cache that detects when the project Dockerfiles or lockfiles change. If dependencies haven't changed, we check cache first, otherwise the image rebuilds as the first step of that pipeline and following pipeline steps use it. Best of both worlds.
Re: Scaling Golang CI by Replacing actions/setup-go
#24Have you considered submitting an upstream patch to the widely used actions/setup-go as well?
Good question — we'd be happy to submit a PR, but it's not clear to me that they'd be interested. Some background: - Our approach writes new cache entries all the time. This can get expensive, and is a pretty big change in behavior from how actions/setup-go works today. - actions/setup-go can basically be considered incredibly critical infrastructure for the public golang ecosystem. Any change in behavior is probably…
Hello! I'm nfi-hashicorp from https://github.com/actions/setup-go/issues/395 :)
My 2c given that that issue has sat in TODO for several years with no movement is that the maintainers probably aren't going to be pursuing too many big swings like that.
End of the day, implementing an efficient GOCACHE with github's cache primitives is untenable for the general case IMO. It works by shipping around big tarballs, and when your cache actually needs fine grained access to thousands of usually tiny files, only a few of which change, you're likely gonna spend more time on transfer and unpacking than you gain with cache hits.
The other thing is, as mentioned elsewhere, it's really hard to measure cache perf at a granular enough level, and aggregate that across jobs, so I'm willing to bet most people don't (outside of this very good post!) and are going off of vibes or napkin math and don't realize they're wasting time caching garbage.
Re: Scaling Golang CI by Replacing actions/setup-go
#25I 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.
I do this occasionally. But it's because my company's security org has a ridiculous policy enforcing 0 CVE images for anything running on our infra (including internal CI images).
In some cases baking a dependency into an image is signing myself up for perpetual toil to keep the image CVE free.