Cached setup-wright Action: remaining acceptance and first release #3

Goal

Add a small, consumer-facing GitHub composite Action inside wright that installs and caches the Wright CLI binary. Repeated jobs/runs should avoid downloading an unchanged Wright release.

Context

Wright already provides:

• immutable versioned native release archives and SHA-256 checksums;
• native GitHub Actions annotations, step summaries, and CLI exit codes;
• its own provider resolution and update contracts.

GitHub Actions supports public Actions defined in repository subdirectories. The initial integration needs no separate repository or independent Action release lifecycle. Consumers can reference wrightkit/wright/.github/actions/setup-wright@<Wright-release-ref> and then run ordinary wright check, wright lint, or wright analyze steps.

Scope

• Implement a lightweight composite Action at .github/actions/setup-wright/action.yml, with only the small supporting script(s) needed.
• Inputs: exact Wright version or latest, and optional binary cache enable/disable. Make the installed wright executable available via PATH to subsequent steps.
• Cache only the Wright CLI executable, using the existing GitHub Actions cache service. Restore before any release-archive download.
• Key the cache by concrete release version, OS, architecture, and cache layout. Do not use a broad restore prefix that could select an incompatible binary.
• For latest, resolve the small latest-version pointer before cache lookup; never redownload the release archive on a valid binary cache hit. For an exact version, a cache hit should require no distribution request.
• On cache miss or invalid cache, download the canonical Wright release artifact, verify SHA-256, extract the executable, and save the verified executable to the cache.
• Reuse Wright's existing CLI rendering/exit behavior; the Action only sets up Wright, leaving command selection, arguments, and workflow gating to ordinary run: wright ... steps.
• Restrict support to platforms with published artifacts, fail clearly on unsupported targets, and use cache permissions safe for untrusted PRs without requiring a write token.
• Document consumer usage, cache identity, version pinning, and the fact that Actions caching is scoped to the consuming repository.
• Use Wright release refs for the bundled Action initially. Do not add an independent Action version/tag scheme without a concrete need.

Non-goals

• No independent wright-action repository or Marketplace listing in this issue.
• No OPY/DEL provider caching; providers remain Wright-managed.
• No Cargo/target cache, source analysis cache, or build-from-source path.
• No second diagnostic/annotation renderer, command wrapper DSL, or GitHub checks/PR-write integration.
• No change to language semantics or Wright's release artifact contract.

Acceptance criteria

• A consumer workflow can reference the Action from a Wright release ref, then run wright check, wright lint, and wright analyze normally, with existing annotations, summary, and exit status preserved.
• An exact-version first run downloads and verifies the CLI; a subsequent compatible run restores the binary without contacting the binary distribution.
• With latest, a current-version metadata lookup does not cause a binary redownload on cache hit; an actual version change installs the new binary.
• OS, architecture, and version changes never silently reuse the wrong executable.
• A corrupt/mismatched cache cannot be executed as a valid Wright binary; recovery downloads and verifies the release or fails explicitly.
• Untrusted PRs cannot poison default-branch caches; normal workflows need no extra repository-write permissions or secrets.
• Focused tests cover cache hit/miss, version resolution, corrupt cache, unsupported platform, and at least one real consuming-workflow smoke. actionlint passes.
• Documentation shows setup once followed by multiple Wright CLI steps, and states that provider/project/build results are not cached.

Dependencies / ownership

• wright: owns this small setup Action, the binary release/checksum contract, and native Actions presentation.
• wrightkit/.github: retains organization-level Rust CI/reusable workflows. No new shared workflow is needed.
• Extract to a separate repository only if independent release cadence, Marketplace publication, or substantial Action-specific maintenance becomes a demonstrated requirement.

Related: Wright reporting wrightkit/wright#164, CI optimization wrightkit/wright#329, workflow simplification wrightkit/wright#338.