You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
I'd like to propose a new input to the action to enable skipping cache saves but maintaining the ability to restore an existing cache.
Something like skip-cache-save.
Justification:
We have the case in our CI/CD where we have the following jobs running in parallel:
Run tests - i.e. runs go test ./...
Run linting - i.e. run golangci-lint
Both jobs benefit from Go package caching but in the above scenario, the linting job finishes first and creates a cache that doesn't contain Go test artefacts. It would be useful to only have 1 job create the cache i.e. the job that populates the package cache and the test/build cache.
I imagine this can be handled by using actions/cache, but this addition feels like a simple way of achieving better cache control without dropping to a lower level tool.
Are you willing to submit a PR?
Possibly, if the feature request is relevant.
The text was updated successfully, but these errors were encountered:
Similar to #495 the caching process takes a long time on our runners. There's no reason to cache by default as Github Actions already has tons of network proxying.
It takes 8s to setup Go in one job, but 2m45s to cache after the job.. Can we disable this post-job caching by default?
Description:
I'd like to propose a new input to the action to enable skipping cache saves but maintaining the ability to restore an existing cache.
Something like
skip-cache-save
.Justification:
We have the case in our CI/CD where we have the following jobs running in parallel:
go test ./...
golangci-lint
Both jobs benefit from Go package caching but in the above scenario, the linting job finishes first and creates a cache that doesn't contain Go test artefacts. It would be useful to only have 1 job create the cache i.e. the job that populates the package cache and the test/build cache.
I imagine this can be handled by using actions/cache, but this addition feels like a simple way of achieving better cache control without dropping to a lower level tool.
Are you willing to submit a PR?
Possibly, if the feature request is relevant.
The text was updated successfully, but these errors were encountered: