2 ms·

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

by JyB 10d ago

peterldowns 10d ago
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. - The current actions/setup-go strictly caches dependencies and ignores the build and modules cache. Our approach could be considered a breaking change. - actions/setup-go can basically be considered incredibly critical infrastructure for the public golang ecosystem. Any change in behavior is probably very risky and slow to happen. At this point I'd bet that we see no change, ever, in behavior. Additionally there are a few relevant issues/prs that have been ignored for years so I'm not optimistic about contributing upstream. Frankly what we've done is write a very small bit of glue code that is likely most effective as a reference for teams writing their own custom caching actions that fit their exact needs: - https://github.com/actions/setup-go/pull/426 https://github.com/actions/setup-go/pull/426 - https://github.com/actions/setup-go/issues/630 https://github.com/actions/setup-go/issues/630 - https://github.com/actions/setup-go/issues/395 https://github.com/actions/setup-go/issues/395 - https://github.com/actions/setup-go/issues/596 https://github.com/actions/setup-go/issues/596 That said we'd be happy if someone used our code and found it valuable! Lukas put a ton of effort into cleaning up my initial version, added the cache trimming, etc. We depend on this for all of our jobs and use it every day and think it's quite good.
- qmuntal 10d ago
  actions/setup-go maintainer here! Great post, I like the ideas in there. We are always open to improvements, but it's true that low-risk ones are preferred. Feel free to submit your ideas to the GitHub issue tracker. I'll do some due diligence myself.
  - peterldowns 10d ago
    Thanks for reading :) Broken down by key idea: - Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache: this is 100% worth upstreaming. I believe there are existing requests and PRs about this. Up to you guys to implement however you see fit. - Allowing "always update the cache": also a good idea to enable as an option, very important for non-open-source teams that are trying to maximize cache hit rate. - Allowing "trim the cache": if you're going to allow always updating the cache, probably a good idea. But the "always update" and "trim" cache changes combine to have a lot of risks regarding cache poisoning that might be bad for open source projects. Lukas may have a different opinion or more to say on this front.
  - lukasschwab 10d ago
    I'd echo Peter's #1 recommendation: > - Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache [...] I'd actually go further: this may be a sensible default behavior. "Always update the cache" can get expensive, but it's a neat one; "trim the cache" is definitely necessary if you enable this in a moderately active repository in our experience. If you want really out-there ideas: rather than storing and loading the full cache monolithically, you could use a GitHub-specific GOCACHEPROG and Go-specific cache service to load only the active items. The pruning problem goes away because accretion is cheap. In theory, parallel jobs could actually share this joint cache. (This may not be a realistic initiative at GitHub.) If you can raise feedback with your colleagues — - The docs and settings for Actions Cache limits are really hard to navigate; at some pointed we desperately wanted to pay GitHub more money for more cache, but couldn't figure out why we were capped. - Bulk-data endpoints for Actions performance would be a boon for optimization projects like this. I wind up either scraping `gh run` (slow) or setting up a GitHub App to collect perf data through webhooks (initially tedious, has to be continuously available). All this aside — actions/setup-go is a pretty well-considered default and an essential part of writing Go on GitHub; ty for your work maintaining it!
    - idkasam 9d ago
      [flagged]
- nfirvine 9d ago
  Hello! I'm nfi-hashicorp from https://github.com/actions/setup-go/issues/395 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.
- idkasam 9d ago
  Try other runners that have smart Caching instead.
tonymet 10d ago
Not OP but upstream patches are rarely worth it. Better to share the fork and if the upstream is interested they can integrate. Integration, testing, meeting upstream expectations usually takes 10x the time, and can be handled faster by those with experience.

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

by JyB 10d ago

Have 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. - The current actions/setup-go strictly caches dependencies and ignores the build and modules cache. Our approach could be considered a breaking change. - actions/setup-go can basically be considered incredibly critical infrastructure for the public golang ecosystem. Any change in behavior is probably very risky and slow to happen. At this point I'd bet that we see no change, ever, in behavior. Additionally there are a few relevant issues/prs that have been ignored for years so I'm not optimistic about contributing upstream. Frankly what we've done is write a very small bit of glue code that is likely most effective as a reference for teams writing their own custom caching actions that fit their exact needs: - https://github.com/actions/setup-go/pull/426 https://github.com/actions/setup-go/pull/426 - https://github.com/actions/setup-go/issues/630 https://github.com/actions/setup-go/issues/630 - https://github.com/actions/setup-go/issues/395 https://github.com/actions/setup-go/issues/395 - https://github.com/actions/setup-go/issues/596 https://github.com/actions/setup-go/issues/596 That said we'd be happy if someone used our code and found it valuable! Lukas put a ton of effort into cleaning up my initial version, added the cache trimming, etc. We depend on this for all of our jobs and use it every day and think it's quite good.

qmuntal 10d ago
actions/setup-go maintainer here! Great post, I like the ideas in there. We are always open to improvements, but it's true that low-risk ones are preferred. Feel free to submit your ideas to the GitHub issue tracker. I'll do some due diligence myself.
- peterldowns 10d ago
  Thanks for reading :) Broken down by key idea: - Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache: this is 100% worth upstreaming. I believe there are existing requests and PRs about this. Up to you guys to implement however you see fit. - Allowing "always update the cache": also a good idea to enable as an option, very important for non-open-source teams that are trying to maximize cache hit rate. - Allowing "trim the cache": if you're going to allow always updating the cache, probably a good idea. But the "always update" and "trim" cache changes combine to have a lot of risks regarding cache poisoning that might be bad for open source projects. Lukas may have a different opinion or more to say on this front.
- lukasschwab 10d ago
  I'd echo Peter's #1 recommendation: > - Allowing actions/setup-go users to specify a cache key prefix so that they can have more than one golang CI job, each with its own cache [...] I'd actually go further: this may be a sensible default behavior. "Always update the cache" can get expensive, but it's a neat one; "trim the cache" is definitely necessary if you enable this in a moderately active repository in our experience. If you want really out-there ideas: rather than storing and loading the full cache monolithically, you could use a GitHub-specific GOCACHEPROG and Go-specific cache service to load only the active items. The pruning problem goes away because accretion is cheap. In theory, parallel jobs could actually share this joint cache. (This may not be a realistic initiative at GitHub.) If you can raise feedback with your colleagues — - The docs and settings for Actions Cache limits are really hard to navigate; at some pointed we desperately wanted to pay GitHub more money for more cache, but couldn't figure out why we were capped. - Bulk-data endpoints for Actions performance would be a boon for optimization projects like this. I wind up either scraping `gh run` (slow) or setting up a GitHub App to collect perf data through webhooks (initially tedious, has to be continuously available). All this aside — actions/setup-go is a pretty well-considered default and an essential part of writing Go on GitHub; ty for your work maintaining it!
  - idkasam 9d ago
    [flagged]
nfirvine 9d ago
Hello! I'm nfi-hashicorp from https://github.com/actions/setup-go/issues/395 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.
idkasam 9d ago
Try other runners that have smart Caching instead.

tonymet 10d ago

Not OP but upstream patches are rarely worth it. Better to share the fork and if the upstream is interested they can integrate. Integration, testing, meeting upstream expectations usually takes 10x the time, and can be handled faster by those with experience.