Support pr N and other deno upgrade-supported specs in deno-version

[steve02081504]

Summary

denoland/setup-deno's deno-version input only accepts release channels (latest, lts, rc, canary), semver ranges, or commit hashes. It does not accept the same specs the deno upgrade CLI supports, most notably pr N (install a specific GitHub PR build).

Motivation

deno upgrade gained a pr positional (and --pr flag) that installs the CI build of a specific denoland/deno pull request, e.g.:

deno upgrade pr 36606

This is very useful for validating an unmerged deno fix in your own CI (here: fount, which runs fount test / server / shell verification). Without setup-deno support, workflows must work around it by installing canary and then running deno upgrade pr N as a separate step — the pin then can't be applied at install time.

Request

Make deno-version accept the full set of specs that deno upgrade understands, or add a dedicated input (e.g. deno-upgrade / deno-pr) for these. Concretely, support values like:

• pr 36606 (PR build)
• any other spec deno upgrade accepts

so that:

- uses: denoland/setup-deno@v2
  with:
    deno-version: pr 36606

works and installs the PR build directly.

Additional context

• deno upgrade usage: deno upgrade [OPTIONS] <VERSION-OR-HASH-OR-CHANNEL> [PR-NUMBER-POSITIONAL], plus --pr <VALUE>

Thanks for considering it.

[steve02081504]

Maintainer note: what this project (fount) would change if implemented

We already added a temporary .deno-version pin mechanism, but today it has to split between install-time and post-install handling because setup-deno can't take pr N. If this feature ships, we'd simplify as follows:

Current workaround (see fount repo, branch theme-radius):

• .github/workflows/scripts/resolve_deno_version.sh — inspects .deno-version; if the spec is a channel/semver/hash it goes into setup-deno's deno-version directly; if it's pr N it installs canary then runs deno upgrade -q pr N as a separate step.
• The polyglot_nop_tests workflow uses install.sh (latest-only) and always applies the pin post-install via a separate script.

After support lands, we'd:

1. Drop the pr special-casing and the post-install deno upgrade fallback step — just pass the raw .deno-version contents straight to deno-version: pr 36606.
2. Collapse resolve_deno_version.sh back to a single value.
3. Keep the same single-line .deno-version file format; no other changes needed on our side.

So the only thing we ask is that deno-version accept everything deno upgrade does (especially pr N), ideally transparently. A separate deno-pr/deno-upgrade input would also work — either way our current split logic becomes unnecessary.