feat: add built-in caching via inputs #89
+164
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for built-in caching to
denoland/setup-deno
. I tried to take inspiration from howactions/setup-node
did things, but the code here can be way simpler because we're only supporting downloads by Deno and the default cache location orDENO_DIR
.TODO's
There is only one thing left to do before this PR is ready. And that's to either install
@actions/cache
and it's dependencies and push the changes. Though@actions/cache
has a large set of dependencies, which is a shame... I'm not sure if just installing them as-is is a good idea, or if the code here now requires a bundling step or not.I thought it best to open this PR first to see if the Deno team has a preference here. Since I am using Windows, installing and pushing from my machine would make a lot of inconsistent changes with current
/node_modules
folder. It's probably also better if checked in/node_modules
are updated by a Deno team member.npm install
and commit+push changes, or introduce a build step?Cache keys
restoreKey
:deno-cache-${env.RUNNER_OS}-${env.RUNNER_ARCH}
${restoreKey}-${env.GITHUB_JOB}-${input.cache-hash}
One difference compared to the existing
setup-node
action, is that I includedGITHUB_JOB
in the cache key. This means it's possible to restore a cache from another job, but each job will have it's own cache key.The benefit of including the job in the cache key, is we only download necessary files. For instance,
test
may download@std/testing
, while other jobs do not. We also avoid corrupted caches, if e.g. abuild
job installs all dependencies except testing dependencies, then the cache will miss files needed by atest
job, even while using the same cache key.This is no issue for other package managers in NodeJS, which installs all packages. But with Deno, it's possible to install packages/files automatically while running a program. The user of this action can solve that themselves though, by adding to the
cache-hash
input (e.g.cache-hash: test-${{ hashFiles(...) }}
).cache-hash
input for more granular cachesbuild
/test
jobs have the same cache key, thus keeps downloading dependencies for one or the otherUsage comparison
Given the requirements below, here's before/after compared to when being able to use the
setup-deno
action with changes in this PR:DENO_DIR
filesrestore-keys
for the following benefits:Making caching of installed dependencies built-in makes it a lot easier and less error prone to get great caching with 1 or 2 extra inputs to
denoland/setup-deno
.Closes #31