setup-deno

Summary 's input only accepts release channels (, , , ), semver ranges, or commit hashes. It does not accept the same specs the CLI supports, most notably (install a specific GitHub PR build). Motivation gained a positional (and flag) that installs the CI build of a specific denoland/deno pull request, e.g.: This is very useful for validating an unmerged deno fix in your own CI (here: fount, which runs / server / shell verification). Without setup-deno support, workflows must work around it by installing and then running as a separate step — the pin then can't be applied at install time. Request Make accept the full set of specs that understands, or add a dedicated input (e.g. / ) for these. Concretely, support values like: (PR build) any other spec accepts so that: works and installs the PR build directly. Additional context usage: , plus Thanks for considering it.

Problem Statement On a large monorepo, with logs and then goes completely silent for minutes until the job is killed. Nothing indicates what it is doing. The cause is the default cache key: when no is supplied the action globs across the whole workspace with symlinks followed, so on a repo that has already run it walks hundreds of thousands of paths to find one lockfile. Passing an explicit makes the same step finish in under two seconds, so the bypass exists — the default just should not be pathological. This matters more than usual right now because #116 proposes enabling by default. Goal With and no , cache-key resolution completes in under 10 seconds on a workspace whose symlink-followed reachable file count exceeds 500,000, while still deriving the key from every in the workspace. Evidence: the glob Source:* and at commit (v2.0.5). Call site: . from defaults to , and a pattern must exhaust the tree — finding the single match early does not stop the walk. Every log line inside is emitted after* the key is computed, which is why the step produces no output at all while it stalls. Evidence: reproduction Reproduced locally with against a real monorepo checkout, container bind-mounted to the workspace: The same workspace, same container, same action, with added: Measurements Workspace: one root (61 lines, two dependencies), populated by pnpm, plus vendored subtrees. Directory walk of the same workspace, measured independently: Top contributors by entry count: 154,204 and vendored subtrees 36,300. The original report that led here was a CI job where the step was cancelled at 5m36s with immediately after — the same signature, just a shorter leash. Orientation Affected: (, ) and . The input already short-circuits the expensive path, so the bypass semantics are established; the question is what the default should do instead. Relevant upstream defaults live in (, ). Non-Counting Outcomes Documenting in the README as a workaround while the default is unchanged. The default is the bug. Setting and nothing else. That walk still took 19 s and visited 290,426 files on this workspace; it narrows the blast radius without fixing the complexity. Restricting the glob to the workspace root only. That breaks multi-package repos that legitimately have nested files, which the current behavior supports. Wrapping the glob in a timeout or abort so a stall becomes a silent cache miss. The job stops hanging and the cache silently stops working. Benchmarking on a clean checkout. The pathological case requires a populated ; a fresh clone will not reproduce it. Acceptance Criteria [ ] (gatekeeper, runnable) A test or benchmark over a fixture workspace containing a pnpm-style symlink tree and one root resolves the default cache key in under 10 s, and fails when the change is reverted. [ ] with no on a workspace with more than 500,000 symlink-followed reachable files resolves a key without exceeding a typical 10-minute job budget. [ ] A workspace with files in nested subdirectories still produces a key derived from all of them, not just the root one. [ ] At least one log line is emitted before key computation begins, so a slow resolution is diagnosable from the job log rather than appearing as a hang. Environment , resolving to v2.0.5 () Deno 2.9.5, Originally observed on a self-hosted Linux runner; reproduced locally with 0.2.89 on

The README documents that can read dvm's , but the parser only accepts a bare version string. dvm writes the file as ( serializes with ), so falls through to the bare-version branch and fails with is a general key/value store rather than a single line, and dvm also records / , so the version is not necessarily on the first line. The new pattern scans every line for the key. It runs only after the existing match, and the two patterns are disjoint, so bare-version and files behave exactly as before. Also tolerates spaces around (dvm's own reader trims both sides) and a prefix, consistent with the existing handling. Validation: , , all pass locally rebuilt , and a second build is byte-identical, so stays clean New job writes a dvm-style with on the second line, so it covers the multi-key case rather than just a prefix strip Exercised the parser locally over 13 cases: dvm single-key / multi-key in both orders / spaces around / prefix / CRLF, plus regressions for bare version, bare range (), , and a string that must not match related: #121