cache

> I need to store artifacts related to this build, as I don’t want to build those again! 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') }} which will allow you to cached based on the hash of a specific deps lock file instead of the commit sha. 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 tho

I disagree with the POV of the article. That said, I do work at Spacelift[0], a specialized CI/CD for Infra as Code (so you can either take this with a grain of salt, or more trust, due to the increased exposure). > 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 lo

This is hitting workflows that use caching [1][2]. - [1] https://github.com/actions/setup-node/issues/516 - [2] https://github.com/actions/cache/issues/820 As of now (11:28 UTC) the status page has been updated. https://www.githubstatus.com

see also https://github.com/actions/cache/issues/820 Looks like the package servers are having troubles. Apparently a workaround is to use the `cache: npm` parameter for the setup-node action. Won't help when you rely on other actions or docker builds etc.

I know. I've been wondering if there's a way this complexity could be buried in the GitHub action for dprint (https://github.com/dprint/check) so people would only have to specify that and everything would just happen, but I'm not sure it's possible at the moment. Caching seems to be limited to needing to use actions/cache (https://github.com/actions/cache)

iirc the biggest issue with `npm ci` before was that it cleared node_modules, which used to be the primary way of caching deps in CI builds, but now most suggest caching ~/.npm[0]. 0: https://github.com/actions/cache/blob/main/examples.md#node-...