pak should not be cached #264
Labels
bug
an unexpected problem or unintended behavior
Comments
|
Ok, we should now exclude the pak directory from the cache, which should fix this issue. |
|
Thanks! Does this mean actions/toolkit#713 has been solved? |
jimhester
added a commit
that referenced
this issue
Apr 15, 2021
This allows the exclusion to work. The exclusions are only applied to the list of files, and directories are not recursed into. So without the wildcard the exclusion will never match. However with a single wildcard it will and do what we want. Fixes #264 (comment)
|
So 0d6c4b3 is a workaround for that issue that does allow the exclusion to succeed, so this should now work as intended. |
|
This issue has been automatically locked. If you believe you have found a related problem, please file a new issue and include a link to this issue |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
In examples workflows using pak, pak's latest version is installed.
However, because the whole library is cached, pak's installation is overwritten by the cached version.
To Reproduce
r-lib/pkgdown#1572 where I needed pak to use a DESCRIPTION field called "Config/Needs/website". I use it twice, once before the cache step, one after that. The first time things work fine because pak's latest version is installed, the second time there is a failure because pak from the cache is used.
Expected behavior
I would expect the workflow to install and use the latest pak version throughout.
Additional context
I found actions/toolkit#713 which isn't solved yet, so one cannot exclude pak from the cache path.
Cc @gaborcsardi @hadley
The text was updated successfully, but these errors were encountered: