-
UpdateThe beta version is released and available for everyone to test. 🚨🚨 ANNOUNCEMENT 🚨🚨 Hey everyone, 👋🏽 Over a period of time, many users have shared feedback about the need for better control of when to save/restore a cache. Currently cache action attempts a restore of a cache, and if there is no exact match, then the cache is saved during the ProposalWe will be releasing two new actions in the coming weeks. These will be in addition to the existing
As their names suggest, these new actions will have the ability to just restore and save the cache respectively. This allows a workflow to have individual restore and save steps instead of relying on a single cache action which internally does both. This also opens up an opportunity to control conditions for specific steps so as to skip restore or save on need. Inspired from: #46 ExamplesUse case 1:In case of multi-module projects, where the built artifact of one project needs to be reused in subsequent child modules, the need of rebuilding the parent module again and again with every build can be eliminated. The Workflow for building the parent module and save it
Workflow for restoring the built artifact from cache using the same key and path
Use case 2:There are instances where some flaky test cases would fail the entire workflow and users would get frustrated because the builds would run for hours and the cache couldn't get saved as the workflow failed in between. For such use-cases, users would now have the ability to use Inspired from: #92, #272, #849
Use case 3:Some technologies like dot-net generate the lockfiles during the build time, due to which the already evaluated Inspired from: #989 We will also be making the restore inputted Let's say we have a restore step that computes key at runtime.
Case 1: Where an user would want to reuse the key as it is
Case 2: Where the user would want to re-evaluate the key
ConclusionThere are many other use cases that can be tackled by gaining this granular control of cache restore and cache save actions. These two new actions will be present in the same actions/cache repository and will share most of the code ensuring consistency in behavior Please note that These will be soon made available for testing as part of our beta release. Please drop any feedback or suggestions that you might have regarding this change in the comments section. We are happy to listen. 😊 |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 17 replies
-
Well to be able to solve the requirements from #901 there needs to be an |
Beta Was this translation helpful? Give feedback.
-
This proposal seems great. A key advantage is that it allows you to save the cache earlier in the workflow e.g. could save it after doing a big download or build but before running (possibly flaky) tests |
Beta Was this translation helpful? Give feedback.
-
Awesome proposal... I look forward to testing it out. |
Beta Was this translation helpful? Give feedback.
-
@kotewar Will the new We still need them both so that we can deal sort-of workaround the situation that the server will not allow us to overwrite an existing cache entry. (This is an issue in the implementation of the cache storage server, not in the action.) Even better would be if the |
Beta Was this translation helpful? Give feedback.
-
Glad to see this finally being adopted in the main project! This functionality is what I have maintained in forks for the past two years, and why I made and shared https://github.com/MartijnHols/actions-cache. This has had some iterations to mature, and it would be great to get parity so I can deprecate that. Here are a few (in my opinion essential) suggestions: A "check" action to check if the a key already exists in the cache. This allows things such as skipping building the app entirely if it already exists in the cache. An old build rarely speeds up building a new build and can be large so you don't want to spend precious time downloading it. This is especially useful in monorepos, where only a few apps need to be build each run. From my Cache build output and skipping build recipe: build:
needs: [install]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
# Using martijnhols/actions-cache/check we check if a cache entry exists without downloading it
- name: Check if "build" is already cached
uses: martijnhols/actions-cache/check@v3
id: cache
with:
path: build
key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', 'patches', 'src', '.babelrc') }}
- name: Restore "node_modules" from cache
# Only execute if the build isn't already in cache
if: steps.cache.outputs.cache-hit != 'true'
uses: martijnhols/actions-cache/restore@v3
with:
path: node_modules
key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', 'patches') }}
required: true
- name: Build app
# Only execute if the build isn't already in cache
if: steps.cache.outputs.cache-hit != 'true'
run: yarn build
# Notice that we do not use a "restore" in this job: the build in our imaginary project can't reuse its own build files so restoring that before building would be a waste of time.
- name: Save "build" to cache
# Only execute if the build isn't already in cache
if: steps.cache.outputs.cache-hit != 'true'
uses: martijnhols/actions-cache/save@v3
with:
path: build
key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', 'patches', 'src', '.babelrc') }}
In order to be able to implement this, you'll need these changes in the actions/toolkit repository: actions/toolkit#1207 A On my fork, I made a few common recipes to showcase possible use-cases. It would be great if all those would be supported so I can deprecate the fork. Looking forward to it! ps. in your examples your use case 3 seems like it wouldn't work to me. Shouldn't this be |
Beta Was this translation helpful? Give feedback.
-
Feedback on current beta branch: Can you help me understand the reason why the If there are no compelling use cases that require it to be conditional, please consider exposing this value unconditionally. Detailed justification (click to expand)
|
Beta Was this translation helpful? Give feedback.
-
Hey everyone, 👋🏽 The beta version is released and available for everyone to test. |
Beta Was this translation helpful? Give feedback.
-
Hey everyone 👋🏽 Two new actions actions/cache/restore and actions/cache/save are now available with tag Do try them and let us know your feedback. We hope these new actions will take care of your use cases. 🙇🏽 |
Beta Was this translation helpful? Give feedback.
Hey everyone 👋🏽
Two new actions actions/cache/restore and actions/cache/save are now available with tag
v3
to everyone for use. These can now be used to achieve granular control on the restore and save steps in the cache action.Do try them and let us know your feedback. We hope these new actions will take care of your use cases. 🙇🏽