feat: include a hash of deno.lock files in the cache key automatically

[dsherret]

No description provided.

[lucacasonato]

It is not clear to me from the readme that there is a restore key and a cache key, and which parts of the cache key are part of which of these keys.

[csvn]

It is not clear to me from the readme that there is a restore key and a cache key, and which parts of the cache key are part of which of these keys.

A cache is not like an artifact, it can be missing or a restored cache that does not match the primary key. The cache-hit output will only match when the cache is restored from the primary key.

Maybe we can add to the README.md that it's only OK to skip deno install when primary cache key hits?

  - uses: denoland/setup-deno@v2
    id: deno
    with:
      cache: true
  - if: steps.deno.outputs.cache-hit != 'true'
    run: deno install

Using the restore key from cache should at worst use a cache with some dependencies that are not used, and the deno install command and post job should then create a new cache. I adapted the existing code from @actions/setup-node which did not explicitly state what the resulting keys are in the README (but they can be seen in the job log).

[dsherret]

It is not clear to me from the readme that there is a restore key and a cache key, and which parts of the cache key are part of which of these keys.

I'm not sure it's useful for someone to know about this? At a high level (from my understanding), the setup-deno action just caches their dependencies at a single key and if they want further granularity they can use @actions/cache, but from my experience setting that up is a PITA to do properly, which is what led me to looking if there was a PR for built-in caching.

[dsherret]

 - if: steps.deno.outputs.cache-hit != 'true'
   run: deno install

One reason I'm hesitent to add an example doing this, is that deno install should be very fast when using caching and it might be setting up a node_modules directory when not using only the global cache.

[csvn]

One reason I'm hesitent to add an example doing this, is that deno install should be very fast when using caching and it might be setting up a node_modules directory when not using only the global cache.

Yeah, this could indeed be described as an advanced pattern (opt-in). So not promoting it sounds reasonable.

The reason I thought including the job-name as part of the cache key is that when not using deno install and just running deno run or deno test, then different sets of dependencies may be needed and thus smaller and granular caches are created.

I think there's pros and cons to both, if every job does deno install then including the job-name as part of the cache key is wasted (creates more unnecessary caches). So in the end it depends a bit on what kind of project it is.

[csvn]

Sorry if I was annoying just jumping in here with my feedback. Just excited to see build-in action caching landed after #89 being merged. Thought it might be a good idea to upgrade my workflow files first after this PR and hopefully a v2 tag update. 😅

[csvn]

My approval doesn't really matter but thought I could chime in since I worked on #89, but looks great to me! Looking forward to this feature! 🎉