feat: add built-in caching via inputs

[csvn]

This PR adds support for built-in caching to denoland/setup-deno. I tried to take inspiration from how actions/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 or DENO_DIR.

- uses: denoland/setup-deno@v2
  with:
    cache: true
    cache-hash: ${{ hashFiles('**/deno.lock') }}

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.

• [ ] Run npm install and commit+push changes, or introduce a build step?

Cache keys

• Cache restoreKey:
  • deno-cache-${env.RUNNER_OS}-${env.RUNNER_ARCH}
• Cache save key:
  • ${restoreKey}-${env.GITHUB_JOB}-${input.cache-hash}

One difference compared to the existing setup-node action, is that I included GITHUB_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. a build job installs all dependencies except testing dependencies, then the cache will miss files needed by a test 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(...) }}).

• Pros
  • Should "just work" as expected when using Deno™️
  • The user of the action only needs to specify cache-hash input for more granular caches
  • Avoids footgun where build/test jobs have the same cache key, thus keeps downloading dependencies for one or the other
• Cons
  • Creates more caches in total (every job will have it's own cache)
  • Cannot opt-out of including the job in the cache key

Usage 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:

• Caches DENO_DIR files
• Cache dependencies on job failures
• Uses restore-keys for the following benefits:
  • Can use cache from other jobs
  • Can re-use cache when lock-file changes

# Now
jobs:
  test:
    runs-on: ubuntu-latest
    env:
      DENO_DIR: ${{ github.workspace }}/.deno
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
      - uses: actions/cache/restore@v4
        id: cache
        with:
          path: ${{ env.DENO_DIR }}
          key: deno-cache-${{ runner.os }}-test-${{ hashFiles('deno.lock') }}
          restore-keys: deno-cache-${{ runner.os }}
      - run: deno test
      - uses: actions/cache/save@v4
        if: always() && steps.cache.outputs.cache-hit != 'true'
        with:
          path: ${{ env.DENO_DIR }}
          key: ${{ steps.cache.outputs.cache-primary-key }}

# This PR
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denoland/setup-deno@v2
        with:
          cache: true
          cache-hash: ${{ hashFiles('deno.lock') }}
      - run: deno test

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

[csvn]

Here's a link to a PR where the Actions passes (after installing node_modules and disabled Windows jobs, since they failed on my fork for some reason).

[csvn]

I've now rebased this PR on top of #95, which address remaining TODO's and issues, as long as bundling is seen as a valid addition by the Deno team. Personally, I think the improved performance and being able to use TS makes it worth it.

[csvn]

Thanks for fixing the remaining lockfile issues and more @dsherret, really glad to have this merged! It should simplify our GitHub Action config a lot 🎉