@developer-guy So this seems to share the cache among releases. But how long is the cache saved on GitHub? Is it longer than our release cycle?

@developer-guy So this seems to share the cache among releases. But how long is the cache saved on GitHub? Is it longer than our release cycle?
👇

@developer-guy Thanks. This is interesting and speeding up the build is of course something we want. However, our use case here is a little bit tricky because we create the release artifact here and we want a newly built artifact instead of reusing the old apt-get install etc result. So I think we cannot use the remote cache here, WDYT?

we want a newly built artifact instead of reusing the old apt-get install etc result.

Unfortunately, not. Because here, we are using the feature provided by the Docker Buildx to store the image layers to address the problem of stateless builds. Because as you might know, GitHub gives us a fresh VM every time we start the build, so there is no way to store the image layers and use them as a cache for further builds. The problem we are solving here is that we (on our behalf, Docker Buildx) store the image layers using GitHub's Cache API feature and use this cache for further builds.

Does that make sense?

kindly ping @ktock

https://github.com/actions/gh-actions-cache