What does HackerNews think of cache?
Cache dependencies and build outputs in GitHub Actions
There's https://github.com/actions/cache though?
https://docs.github.com/en/actions/using-workflows/storing-w...
they do seem to be capable of saving most things people call artifacts or if you are looking for something more along the lines of caching parts of the build for future builds, you can adjust it pretty easily by adjusting what the cache key is based on.
example:
key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
https://docs.github.com/en/actions/using-workflows/caching-d...
https://github.com/actions/cache
The one note here is clearing that cache/cache management isn't straight forward currently (although they are improving it), there are a few acceptable workarounds though.
Not sure if you were aware of these already.
> First, CI rarely knows what has changed, so everything needs to be rebuilt and retested.
Yes, this is an issue with some CI/CD systems, an issue you can solve however. See our Push Policies[1] based on Open Policy Agent. Test-case caching is also sometimes available (available in i.e. Go).
> Running tests pre-commit is one answer.
Running tests locally for a quick feedback loop - sure, that's fairly mainstream though (something you can use our local preview[2] for as well in the case of IaC). Running tests locally before directly deploying to prod - that would be a compliance and security nightmare.
The author presents what looks to me like a very "move fast, break things" attitude, that doesn't really work in a whole lot of cases.
If your CI/CD is slowing you down, make it faster. Easier said than done, I know, but a lot of people don't even think about optimizing their CI/CD, which you often can do, by being smarter about what you run and/or parallelizing extensively and/or caching[3].
[1]:https://docs.spacelift.io/concepts/policy/git-push-policy
[2]:https://docs.spacelift.io/concepts/stack/stack-settings#enab...
See [1] actions/cache for more details.