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.
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.
- 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.
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.
qmuntal · · focus · HN ↗
peterldowns · · focus · HN ↗
- 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.