Skip to content

Cache Deno development cache in CI#14408

Merged
cderv merged 3 commits intomainfrom
feature/deno-ci-caching
Apr 22, 2026
Merged

Cache Deno development cache in CI#14408
cderv merged 3 commits intomainfrom
feature/deno-ci-caching

Conversation

@cderv
Copy link
Copy Markdown
Member

@cderv cderv commented Apr 22, 2026

Every CI run re-downloads Quarto's main Deno development cache — roughly 30s per job across three OS matrix entries. The cache at ./package/dist/bin/deno_cache is wiped at the start of vendor.sh / vendor.cmd and re-populated by a deno install loop. That makes each green run dependent on deno.land availability, so a transient upstream 500 during that window flips the build red.

This PR caches ./package/dist/bin/deno_cache via actions/cache@v5 and coordinates with the vendor scripts so the restored cache survives the configure step.

How it works

Two coordinated changes:

  1. vendor.sh and vendor.cmd gain a conditional guard around the existing pre-install wipe. Default behavior is unchanged — local ./configure.sh still wipes. Only QUARTO_SKIP_DENO_CACHE_WIPE=1 opts into preservation.

  2. .github/workflows/actions/quarto-dev/action.yml adds a cache step and sets QUARTO_SKIP_DENO_CACHE_WIPE=1 on both configure steps, so the restored cache survives through to deno install.

Cache key

Five files drive the hash:

  • configuration — pins the Deno binary version
  • src/import_map.json — top-level dep version mapping
  • src/vendor_deps.ts — main vendor entrypoint
  • tests/test-deps.ts — test deps entrypoint
  • package/scripts/deno_std/deno_std.ts — deno_std entrypoint

The vendor scripts themselves are intentionally not in the key. hashFiles() is OS-independent, so including vendor.sh would cross-invalidate the Windows cache on a Unix-only edit. If cache shape ever changes subtly, the escape hatch is bumping the -v1- version prefix rather than continuous invalidation. Full rationale in dev-docs/ci-deno-caching.md.

Verification plan

  • First CI run after merge: cache-miss expected (no key yet), vendor loop completes within normal runtime
  • Second run (after a no-op commit): cache-hit expected on all three OS jobs, near-zero download time in the vendor loop
  • Invalidation: bumping any one of the five keyed files produces a new cache key (visible in the workflow log)
  • Local default: running ./configure.sh with no env var set still wipes package/dist/bin/deno_cache and re-downloads, as today

No changelog entry

This is a CI/infra-only change with no user-observable behavior; local ./configure.sh is unchanged. Precedent from changelog-1.9.md — CI and infrastructure changes don't get entries.

Expected cache footprint

~150–200 MB per OS, ~600 MB across Linux / macOS / Windows. Well under GitHub's 10 GB per-repo quota.

cderv added 3 commits April 22, 2026 15:20
Default behavior unchanged: local ./configure.sh still wipes deno_cache
before re-vendoring. CI opts into cache preservation by setting
QUARTO_SKIP_DENO_CACHE_WIPE=1, enabling actions/cache to restore the
cache and have it survive vendor.sh.
Windows counterpart to the vendor.sh change. Behavior matches:
default wipes, QUARTO_SKIP_DENO_CACHE_WIPE=1 preserves.
Adds actions/cache restore for ./package/dist/bin/deno_cache, keyed on
the five files that influence Deno dep resolution: configuration,
src/import_map.json, src/vendor_deps.ts, tests/test-deps.ts, and
package/scripts/deno_std/deno_std.ts.

Both configure steps set QUARTO_SKIP_DENO_CACHE_WIPE=1 so the restored
cache survives the configure.sh / configure.cmd run.

Adds dev-docs/ci-deno-caching.md explaining the cache layout, key
composition, env var contract, and how to force invalidation. Adds a
cross-link from dev-docs/upgrade-dependencies.md so a contributor
bumping deno_std version sees the cache consequences.

Expected per-OS cache size ~150-200 MB; total footprint ~600 MB across
Linux/macOS/Windows, well under GitHub's 10 GB repo quota.
@cderv cderv merged commit e4b75c1 into main Apr 22, 2026
90 of 93 checks passed
@cderv cderv deleted the feature/deno-ci-caching branch April 22, 2026 19:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant