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 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:
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.
Hello! I'm nfi-hashicorp from <a href="https://github.com/actions/setup-go/issues/395" rel="nofollow">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.
JyB · · focus · HN ↗
peterldowns · · focus · HN ↗
- 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 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:
- <a href="https://github.com/actions/setup-go/pull/426" rel="nofollow">https://github.com/actions/setup-go/pull/426
- <a href="https://github.com/actions/setup-go/issues/630" rel="nofollow">https://github.com/actions/setup-go/issues/630
- <a href="https://github.com/actions/setup-go/issues/395" rel="nofollow">https://github.com/actions/setup-go/issues/395
- <a href="https://github.com/actions/setup-go/issues/596" rel="nofollow">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.
nfirvine · · focus · HN ↗
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.