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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Update
The beta version is released and available for everyone to test.
Please use the #1028 for instructions on how to try the new actions and give your feedback. 🙇🏽♂️
🚨🚨 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
post
phase of a job. We looked at these feedback and have come up with a solution which aims to address a majority of these feedback.Proposal
We will be releasing two new actions in the coming weeks. These will be in addition to the existing
actions/cache
action which will continue to exist.actions/cache/restore
actions/cache/save
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
Examples
Use 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
actions/cache
oractions/cache/save
action can be used to build and save the parent module artifact once, and restored multiple times while building the child modules.Inspired from: #350, #334
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
actions/cache/save
action to save the cache by usingif: always()
condition. This way the cache will always be saved if generated, or a warning will be thrown that nothing is found on the cache path. Users can also use theif
condition to only execute theactions/cache/save
action depending on the output of the previous steps. This way they get more control on when to save the cache.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
${{ hashFiles('**/lockfiles') }}
hash doesn't match the actual hash. Using save action with the same key will not re-evaluate the key as hash would be calculated after the build step hence allowing the hash to be latest.Inspired from: #989
We will also be making the restore inputted
key
available as output ofrestore
action to be reused in the input of thesave
action. This way the user has to control to reuse the same key or get it re-evaluated based on their choice.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
Conclusion
There 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
actions/cache
action will continue to have the same functionality as earlier.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.
All reactions