## Summary
Adds two new inputs that gate the mise-wings asset cache for tool
installs. Existing workflows are unaffected: default `wings_enabled:
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](https://github.com/jdx/mise/pull/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 run
4. Transparently rewrites `registry.npmjs.org` / `github.com` /
`api.github.com` URLs to the corresponding 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, etc.). 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 correctly flagged the previous
"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.
## Test plan
- [x] `npm run all` — format + lint + package, clean
- [x] `dist/index.js` rebuilt and contains the wings hook (greppable:
`MISE_WINGS_ENABLED`, `setupWings`)
- [ ] End-to-end: a workflow with `wings_enabled: true`, `permissions:
id-token: write`, an active wings subscription, and a recent enough
`mise` binary. The mise repo's own `docs.yml` will exercise this path
once [jdx/mise#9458](https://github.com/jdx/mise/pull/9458) is merged.
- [ ] Default-off path: a workflow without the `wings_enabled` input
behaves identically to today.
## Out of scope
- Older mise binaries will see `MISE_WINGS_ENABLED` and silently ignore
it (no wings client code) — that's intended; the action doesn't gate on
mise version.
- Self-hosted runners: `permissions: id-token: write` only does anything
on GitHub-hosted runners by default. Self-hosted runners need extra
config; the warning above is conservative enough for both cases.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Introduces an opt-in path that can cause OIDC-based authentication to
a third-party cache and alters tool download routing when enabled.
Default-off behavior limits impact, but misconfiguration could create
confusing cache bypass or unexpected network/token exchange behavior.
>
> **Overview**
> Adds a new **experimental** `wings_enabled` action input (default
`false`) to opt workflows into the mise-wings asset cache by exporting
`MISE_WINGS_ENABLED=1`.
>
> When enabled, the action now runs `setupWings()` early to set the env
var and warn if GitHub OIDC env vars are missing (i.e., `permissions:
id-token: write` not configured), while leaving existing/default
behavior unchanged.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
969042fe52. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Fixes https://github.com/jdx/mise-action/issues/394
This PR updates the GitHub Actions runner environment to use Node.js 24,
following the deprecation notice for Node.js 20. GitHub has announced
that starting June 2, 2026, Node.js 24 will become the default, and
earlier versions will be restricted to ensure security and performance
standards.
The jdx/mise-action@v3 currently triggers a deprecation warning because
it defaults to the Node.js 20 runtime. To proactively address this and
avoid potential workflow failures during the transition period, we are
opting into the newer runtime version now.
Co-authored-by: jdx <216188+jdx@users.noreply.github.com>
## Summary
Refs #382 (Problem 1).
The default cache key template placed `file_hash` before conditional
segments (`version`, `mise_env`, `install_args_hash`). Because
`@actions/cache` `restoreCache` performs prefix matching on the primary
key, a key without optional trailing segments was always a prefix of a
key with them, causing different workflow configurations to restore each
other's caches unintentionally.
## The bug
Old template:
```
{{cache_key_prefix}}-{{platform}}-{{file_hash}}{{#if version}}-{{version}}{{/if}}{{#if mise_env}}-{{mise_env}}{{/if}}{{#if install_args_hash}}-{{install_args_hash}}{{/if}}
```
Example: Workflow A (no `install_args`) produces key
`mise-v0-linux-x64-<hash>`, which is a prefix of Workflow B's key
`mise-v0-linux-x64-<hash>-<args_hash>`. If only B's cache exists, A
restores it via prefix match.
## The fix
Move `file_hash` to the end of the template so it acts as a terminator:
```
{{cache_key_prefix}}-{{platform}}{{#if version}}-{{version}}{{/if}}{{#if mise_env}}-{{mise_env}}{{/if}}{{#if install_args_hash}}-{{install_args_hash}}{{/if}}-{{file_hash}}
```
Since `file_hash` is always present, no valid cache key can be a prefix
of another.
Also bumps `cache_key_prefix` default from `mise-v0` to `mise-v1` (in
both `src/index.ts` and `action.yml`) to intentionally invalidate
existing caches that may have been saved under incorrect prefix-matched
keys.
## Changes
- `src/index.ts` L43: Reorder `DEFAULT_CACHE_KEY_TEMPLATE` — move
`file_hash` to end
- `src/index.ts` L432: Bump fallback `cache_key_prefix` from `mise-v0`
to `mise-v1`
- `action.yml` L46: Bump default `cache_key_prefix` from `mise-v0` to
`mise-v1`
- Rebuilt `dist/`
## Summary
- Add `add_shims_to_path` input (default: `true`) to control whether the
mise shims directory is added to PATH
- Setting this to `false` allows users who already have mise configured
to avoid conflicts with their existing setup
Fixes#337
## Usage
```yaml
- uses: jdx/mise-action@v2
with:
add_shims_to_path: false
```
## Test plan
- [ ] Verify shims are added to PATH by default (existing behavior)
- [ ] Verify shims are NOT added to PATH when `add_shims_to_path: false`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds `add_shims_to_path` input (default true) to optionally skip
adding `mise/shims` to PATH.
>
> - **Action input/behavior**
> - Add `inputs.add_shims_to_path` (default: `true`).
> - Conditionally add `mise/shims` to `PATH` only when
`add_shims_to_path` is `true`.
> - **Build/dist updates (non-functional to action API)**
> - Minor runtime tweaks in bundled libs: safer `abortSignal`
reassignment, improved `File` stream creation, user-agent OS field
formatting, `randomUUID` fallback for Node, and updated internal SDK
version constants.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
f90b26afa3. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
I added support for customizing the key, but forgot the most important
piece that we need, being able to reference an environment variable
value. Our CI runner provider is now exposing an environment variable
that indicates if the OS configuration changes, and we plan to use that
one to invalidate the cache, otherwise we get errors because the cached
dependencies are linking against an invalid / non-existent `glibc`
version.
> [!IMPORTANT]
> I wrote the code with `claude code` and reviewed it afterwards
## Summary (Claude-generated)
- Add support for `{{env.VAR_NAME}}` syntax in cache key templates to
allow reading environment variable values
- Enables more flexible cache key customization based on CI/CD
environment variables like branch names, deployment environments, or
custom build identifiers
- Maintains backward compatibility with existing cache key templates
## Examples
```yaml
# Include branch name from environment
cache_key: 'mise-{{env.GITHUB_REF_NAME}}-{{platform}}-{{file_hash}}'
# Use custom deployment environment
cache_key: 'mise-{{env.DEPLOY_ENV}}-{{platform}}-{{file_hash}}'
# Conditional logic with environment variables
cache_key: '{{default}}{{#if env.CUSTOM_SUFFIX}}-{{env.CUSTOM_SUFFIX}}{{/if}}'
```
## Changes
- Modified `processCacheKeyTemplate()` in `src/index.ts` to include
`process.env` in template data
- Updated `action.yml` documentation to include the new
`{{env.VAR_NAME}}` syntax
- All existing functionality remains unchanged
## Test plan
- [x] Build and package successfully with `npm run all`
- [x] Linting and formatting pass
- [ ] Manual testing with environment variables in cache key templates
- [ ] Verify backward compatibility with existing cache key
configurations
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
* support checksum
