Skip to content

feat: cache the verified dprint download when caching is enabled - #28

Merged
dsherret merged 8 commits into
mainfrom
cache_download
Sep 6, 2026
Merged

feat: cache the verified dprint download when caching is enabled#28
dsherret merged 8 commits into
mainfrom
cache_download

Conversation

@dsherret

@dsherret dsherret commented Sep 5, 2026

Copy link
Copy Markdown
Member

With cache: true, the downloaded zip is cached per version and platform under the key dprint-executable-{os}-{arch}-{version}.

  • Resolve first: a single gh release view call (0.4s) returns the latest tag and every asset's SHA-256 digest, so the exact cache key is known before the restore and "latest" stays correct.
  • On a hit, the cached zip's SHA-256 is checked against the release's digest fetched live from GitHub, and the 4-second attestation verification is skipped: the same bytes were verified when first cached, and the digest check means a poisoned cache entry can't substitute a different binary. A mismatch falls back to a fresh download and verification.
  • On a miss, the zip is downloaded, verified, and saved only after verification succeeds.
  • Only releases whose assets have digests are cached (all attested releases do), so older pinned versions behave exactly as before.

Verified locally by simulating miss, hit, tampered hit, an unattested pinned version, a version without digests, and verification disabled. Hit path is about 1.5 seconds instead of 5.

Also updates the README to actions/checkout@v7.

With `cache: true`, the downloaded zip is cached per version and platform.
On a hit, its digest is checked against the release's digest from the
GitHub API, which is fetched anyway when resolving the version, and the
attestation verification is skipped since the same bytes were verified when
they were first cached. That takes the install from about 5 seconds to 1.5.

Also updates the README to actions/checkout@v7.
…sted version

Also skips the release lookup when caching is disabled since the download
step gets the latest release itself, sends the token on the curl fallback,
and adds a `dprint-version` output that the tests assert on.
…oads

GNU sha256sum prefixes its output with a backslash when the file name
contains one, which every Windows path does, so the cached download never
matched the release's digest on Windows and was re-downloaded every run.
Hashing via stdin avoids the escaping.

Also only saves a download that was attestation verified, includes the
asset's digest in the cache key so a re-uploaded asset gets its own entry,
and logs when a cached download is discarded.
A second job could land on a runner with different cpu features, which
compiles its own plugin variants and changes the cache, and re-running only
the failed jobs lost the entry the first job saved because the unique config
includes the run attempt.
@dsherret
dsherret merged commit d833cf2 into main Sep 6, 2026
14 checks passed
@dsherret
dsherret deleted the cache_download branch September 6, 2026 14:24
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