Deno DENO_DIR cache not restored (slow re-download) in CI

Deno stores fetched modules and type-checks in DENO_DIR. When CI does not cache and restore that directory, every job refetches all dependencies and recompiles, adding minutes and exposing the run to network flakiness.

What this error means

Each CI run spends time on "Download https://..." lines for the same modules, and deno cache or deno test is consistently slow even with no dependency changes.

deno

Download https://jsr.io/@std/assert/1.0.0/mod.ts
Download https://jsr.io/@std/path/1.0.0/mod.ts
Download npm:express@4.19.2
... (repeated every run)

Common causes

DENO_DIR is not persisted between runs

Without an actions/cache step for the Deno cache directory, each job starts with an empty cache and refetches everything.

A cache key that always misses

A key not tied to deno.lock (or one that changes every run) never restores, so the cache is effectively unused.

How to fix it

Cache DENO_DIR keyed on the lockfile

Set the DENO_DIR location if needed and cache it.
Key the cache on deno.lock so it restores when dependencies are unchanged.
Restore before the cache/build step.

.github/workflows/ci.yml

- uses: actions/cache@v4
  with:
    path: ~/.cache/deno
    key: deno-${{ runner.os }}-${{ hashFiles('deno.lock') }}

Warm the cache once, reuse across steps

Run deno cache early to populate DENO_DIR, then reuse it for check, test, and run.

Terminal

deno cache main.ts

How to prevent it

Always cache and restore DENO_DIR keyed on deno.lock.
Warm the cache with deno cache before test and build steps.
Avoid cache keys that change on every run.