mirror of
https://github.com/jdx/mise-action.git
synced 2026-05-14 13:50:33 +00:00
Adds a single new input — `wings_enabled` — that gates the [mise-wings](https://mise-wings.en.dev) asset cache for tool installs. Existing workflows are unaffected: default `false` is a no-op. | Input | Default | Description | |---|---|---| | `wings_enabled` | `false` | Route tool-install URLs through the wings cache when `true` | ## How it works When `wings_enabled: true`, the action exports `MISE_WINGS_ENABLED=1`. Authentication is fully automatic — mise itself owns the GHA OIDC → wings session exchange. No `mise wings login` step in workflow YAML, no long-lived secrets to rotate. When mise (built with wings support — see jdx/mise#9458) sees `MISE_WINGS_ENABLED=1` and detects the GHA OIDC env vars (`ACTIONS_ID_TOKEN_REQUEST_URL` + `ACTIONS_ID_TOKEN_REQUEST_TOKEN`), it: 1. Fetches the runner's OIDC token, scoped to the wings deployment audience 2. POSTs it to `https://api.<host>/auth` to mint a wings CI session JWT 3. Caches the JWT in-process for the rest of the workflow 4. Transparently rewrites `registry.npmjs.org` / `github.com` / `api.github.com` URLs to the wings cache subdomains and attaches the JWT as a Bearer header ## Why opt-in (not opt-out) The default-off posture is deliberate. Many workflows already declare `permissions: id-token: write` for unrelated reasons (SLSA provenance, AWS OIDC, Sigstore, npm provenance). If `wings_enabled` defaulted to `true`, those workflows would silently send the runner's OIDC identity claims to a third-party cache without explicit consent. Cursor Bugbot HIGH + Greptile P1+security flagged a prior "default true" iteration of this PR as a privacy regression. Explicit opt-in keeps the gate visible in the workflow YAML. ## Workflow requirements ```yaml permissions: id-token: write # required for OIDC jobs: build: steps: - uses: jdx/mise-action@<sha> with: wings_enabled: true ``` The action emits a clear warning when `wings_enabled: true` but `id-token: write` is missing — without that hint, the user would see "wings configured but doing nothing" and have no clue why. ## Notes - Older mise binaries see `MISE_WINGS_ENABLED` and silently ignore it — forward-compatible. - `setupMise` fetches the mise binary itself with `curl`, which doesn't go through mise's HTTP layer; the wings rewriter only kicks in once the resulting mise binary runs `mise install`. The action sets the env var before any `mise` subcommand runs. |
||
|---|---|---|
| .. | ||
| index.js | ||
| index.js.map | ||
| licenses.txt | ||