-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: cmd/go: make build cache trimming cutoff configurable #69879
Comments
Another option that just came to mind is to expose cache trimming on the tool chain to be able to explicitly call it with various some configurability as well. |
Related Issues and Documentation (Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
@ianlancetaylor @matloob I wanted to put this on your radar. I like the P.S. @ianlancetaylor you were my go code readability reviewer in another life 👋 |
@matthalp Have you looked at GOCACHEPROG (it is currently not enabled by default but there's an accepted proposal to do so in 1.24)? You could use it to implement a cache with a custom policy. |
Thank you @matloob! I had not seen that before. I can look into a custom cache implementation, but I feel like my use case -- as well as the one in #69565 -- would be enabled by making variables configurable in some way. Is that something you would be open to? From https://cs.opensource.google/go/go/+/refs/tags/go1.23.3:src/cmd/go/internal/cache/cache.go;l=334-335
|
@matthalp I don't think that's something we'd want to do unless we had a strong reason for it. Each additional bit of configuration adds complexity to the command and we'd need to have a strong reason to add it to balance out the complexity. |
Proposal Details
The current policy assumes that caching is being used by a single developer. However, there are scenarios where the cache is shared across multiple developers and the cache size accumulation can have meaningful impact.
For example, CI where there can be many developers contributing code in a single day and leveraging a shared cache (e.g. GitHub Actions Cache where there is a cache size limit and also time spent loading and saving the cache). In these cases, 5 days of cache accumulation can have meaningful impacts.
Thank you for your consideration!
The text was updated successfully, but these errors were encountered: