chore(deps): update https://github.com/jdx/mise-action action to v5 #32

2026-10-02T03:17:14+02:00

renovate-bot commented

2026-10-02 03:17:14 +02:00

This PR contains the following updates:

Package	Type	Update	Change
https://github.com/jdx/mise-action	action	major	`v4.3.0` → `v5.1.1`

Release Notes

jdx/mise-action (https://github.com/jdx/mise-action)

`v5.1.1`: : GitHub token is no longer exported to later steps by default

Compare Source

mise-action no longer exports its GitHub token as MISE_GITHUB_TOKEN to every later step in the job. A new persist_github_token input lets you turn that back on, or pass a different token to later steps. This changes the default behavior. If later steps need the token, see Breaking Changes below.

Fixed

The GitHub token now stays inside the action by default. Before this release, the github_token input (which defaults to ${{ github.token }}) was written to GITHUB_ENV as MISE_GITHUB_TOKEN. That let any later step read the token and call the GitHub API with the job's permissions, even if the step never asked for a credential. Now the token is set only for the mise-action step and the processes it starts. The action masks the token in logs. (#658 by @jdx, reported in #657)

Added

persist_github_token input (default false). It takes one of three values:
- false: the token stays inside the action.
- true: the token the action used is exported to later steps. If env.MISE_GITHUB_TOKEN is already set, it takes precedence over github_token.
- A token value: that token is exported to later steps instead, for example a read-only token. The action still installs tools with github_token, or with MISE_GITHUB_TOKEN if it's already set.
Setting false doesn't clear a MISE_GITHUB_TOKEN that was already set at the job level or exported by an earlier step. (#658 by @jdx)

Breaking Changes

Check your workflow if a later step needs MISE_GITHUB_TOKEN, such as mise shims, mise exec, mise run or lazy tool installs that call the GitHub API. Those steps no longer get the token automatically and may hit GitHub API rate limits. To get the old behavior back, opt in:

- uses: jdx/mise-action@v5
  with:
    persist_github_token: true

Or give later steps a separate token:

- uses: jdx/mise-action@v5
  with:
    persist_github_token: ${{ secrets.READ_ONLY_TOKEN }}

Full Changelog: https://github.com/jdx/mise-action/compare/v5.1.0...v5.1.1

`v5.1.0`: : Tool version outputs, plugins input, and cached mise reuse

Compare Source

mise-action now reports the tool versions it installed as step outputs, can install mise plugins before tools, and can save the cache at the end of the job. Several caching fixes stop the action from downloading mise again on every run.

Added

Tool versions as step outputs. After install, the action runs mise ls --json --current and sets a versions output. This is a JSON object of the active, installed tools. Each tool maps to a list of {version, requested_version, install_path, source} entries. Each tool also gets its own output with its resolved version, such as steps.mise.outputs.node. A tool only gets its own output if its name is a valid output name and isn't cache-hit or versions. Names like npm:@scope/pkg appear only in versions. If the action can't read the versions, it prints a warning and the step still succeeds. (#655 by @jdx)
```
- uses: jdx/mise-action@v5
  id: mise
- run: echo "node ${{ steps.mise.outputs.node }}"
```
plugins input. List plugins one per line as name or name url. Blank lines and # comments are ignored. The action runs mise plugins install -y for each one before mise install. Plugins that are already installed, for example restored from the cache, are left as they are. An unknown plugin fails the step. When plugins is set, its hash is added to the default cache key. Custom cache_key templates can use it as {{plugins_hash}}. If plugins is unset, existing cache keys don't change. (#656 by @jdx)
```
- uses: jdx/mise-action@v5
  env:
    # needed for idiomatic files such as .yvmrc
    MISE_IDIOMATIC_VERSION_FILE_ENABLE_TOOLS: yarn
  with:
    plugins: |
      yarn
      php https://github.com/verzly/mise-php#latest
```
cache_save_post input (opt-in, default false). When enabled, the mise cache is saved in the action's post step instead of right after install. This way, tools installed by later steps are included in the cache, for example from monorepo sub-project configs or task-level tools. The setting only applies on a cache miss, because an existing cache entry can't be overwritten. The post step runs even if a later step fails. If the post-step save fails, the action prints a warning and the job doesn't fail. (#649 by @jdx)
auto_update input (default false). See Changed below. (#642 by @jdx)
The action now warns when you use the mise_toml input and a .mise.toml already exists in the working directory. mise loads .mise.toml before the mise.toml the action writes, so the input may have no effect. (#654 by @jdx)

Changed

A cached mise is kept when version is unset. Before, each new mise release made the action reject the cached binary in integrity verification and download mise again on every run until the cache key changed. Now the cached binary is kept until the cache key changes. The action verifies it against the signed checksums of the version recorded at install, without running it first. Caches saved before this release have no version record, so they are still verified against the latest release, and a tampered binary is still replaced. The integrity warning now includes the underlying error. To keep updating to newer releases as before, set auto_update: true. Each updated binary is cached under its own mise version, so each release is downloaded only once. An explicit version input works the same as before. (#642 by @jdx)

Fixed

The cache is saved after a partial-match restore. When the cache was restored from a key that only matched the prefix, the action never saved under the primary key, so it rebuilt the same tools on every run. Exact cache hits still skip the save. (#646 by @jdx)
Caches saved before this release no longer cause a download on every run. These caches have no version record, so a cached binary is verified against the latest release. Once a newer mise shipped, the action downloaded mise again on every run. It now also saves the reinstalled binary in a cache keyed by mise version, so later runs restore that binary instead of downloading it. (#648 by @jdx)
Windows: mise installs without unzip. The mise zip is now extracted with PowerShell's Expand-Archive. Self-hosted Windows runners that don't have unzip, such as fresh Windows 11 arm64 machines, can now install mise. (#650 by @jdx)

Documentation

New README guides cover matrix builds, using another cache action, and Rust caching:
- Matrix builds: use MISE_<TOOL>_VERSION overrides and give each matrix entry its own cache_key.
- Other cache actions: set cache: false and cache mise's data directory yourself.
- Rust: explains why a restored cache can be missing Rust components such as rustfmt, with two workarounds. (#654, #651 by @jdx)

Full Changelog: https://github.com/jdx/mise-action/compare/v5.0.1...v5.1.0

`v5.0.1`: : Verify cached mise binaries before running them

Compare Source

mise-action now checks the integrity of an already-installed mise binary before running it. This fixes a security issue that was reported privately.

Fixed

An existing mise binary is verified before it is run. When a mise binary is already on the runner (for example, restored from cache or in mise_dir), the action now checks it before calling it. If you set a sha256 input, the binary must match that checksum and report the requested version. Otherwise, it must match the signed release checksums for the version being installed. If the check fails, the action prints a warning, deletes the binary and installs the requested release again. Before this fix, the action could run a cached binary before checking it. (#637 by @jdx)

Changed

Changes to how the action handles an existing binary, also from #637:

Switching versions uses a full install. If the cached binary doesn't match the requested version, the action downloads and installs that version. It no longer runs mise self-update.
Unpinned runs always pick a release. Without a version input, the action now selects a release every time, using minimum_release_age, even when mise is already installed. It then checks the existing binary against that release, and reinstalls if the binary doesn't match.
Older releases need a sha256 input to reuse a cached binary. Some older mise releases have no signed checksums. With the sha256 input set, a cached binary of one of these releases can still be reused without a download. Without it, the action can't verify the binary and installs it again.

Full Changelog: https://github.com/jdx/mise-action/compare/v5.0.0...v5.0.1

`v5.0.0`: : Default minimum release age of 24 hours for mise

Compare Source

If you don't pin a version, mise-action now installs the newest stable mise release that is at least 24 hours old. Upgrading mise on a runner that already has it is also less likely to hit GitHub API rate limits.

Breaking Changes

`minimum_release_age` now defaults to `24h` (#632 by @jdx)

Before this release, minimum_release_age was an opt-in setting. It now defaults to 24h. If you don't set version, the action picks the highest-numbered stable mise release published at least 24 hours ago. A mise release that just shipped won't be installed until it's a day old.

To get the latest stable release right away, as in v4, set the delay to 0s. You can also choose a longer delay:

- uses: jdx/mise-action@v5
  with:
    minimum_release_age: 0s   # or e.g. 7d

An explicit version input still takes precedence and skips the delay.
The setting applies only to the mise binary, not to tools installed by mise.
The action now gets the release list from a public CDN index (releases.tsv on mise.jdx.dev) instead of paging through the GitHub Releases API. Picking a release doesn't use GitHub API quota, even when an installed binary is reused. If the index is missing or malformed, the action fails instead of skipping the release-age check.
Replacing an older installed binary still runs mise self-update, which may call the GitHub API to fetch that exact release.

Fixed

mise self-update now runs with MISE_GITHUB_TOKEN. When a runner already had a different mise version installed, the action runs mise self-update to switch versions. That GitHub API call used to go out without authentication, so busy shared or self-hosted runners could hit the rate limit and fail with HTTP 403 RateLimitedError. If you already set a token in your environment, the action leaves it unchanged. (#619 by @hegde5)

New Contributors

@hegde5 made their first contribution in #619

Full Changelog: https://github.com/jdx/mise-action/compare/v4.3.0...v5.0.0

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [https://github.com/jdx/mise-action](https://github.com/jdx/mise-action) | action | major | `v4.3.0` → `v5.1.1` | --- ### Release Notes <details> <summary>jdx/mise-action (https://github.com/jdx/mise-action)</summary> ### [`v5.1.1`](https://github.com/jdx/mise-action/releases/tag/v5.1.1): : GitHub token is no longer exported to later steps by default [Compare Source](https://github.com/jdx/mise-action/compare/v5.1.0...v5.1.1) mise-action no longer exports its GitHub token as `MISE_GITHUB_TOKEN` to every later step in the job. A new `persist_github_token` input lets you turn that back on, or pass a different token to later steps. **This changes the default behavior.** If later steps need the token, see Breaking Changes below. #### Fixed - **The GitHub token now stays inside the action by default.** Before this release, the `github_token` input (which defaults to `${{ github.token }}`) was written to `GITHUB_ENV` as `MISE_GITHUB_TOKEN`. That let any later step read the token and call the GitHub API with the job's permissions, even if the step never asked for a credential. Now the token is set only for the mise-action step and the processes it starts. The action masks the token in logs. ([#658](https://github.com/jdx/mise-action/pull/658) by [@jdx](https://github.com/jdx), reported in [#657](https://github.com/jdx/mise-action/issues/657)) #### Added - **`persist_github_token` input (default `false`).** It takes one of three values: - `false`: the token stays inside the action. - `true`: the token the action used is exported to later steps. If `env.MISE_GITHUB_TOKEN` is already set, it takes precedence over `github_token`. - A token value: that token is exported to later steps instead, for example a read-only token. The action still installs tools with `github_token`, or with `MISE_GITHUB_TOKEN` if it's already set. Setting `false` doesn't clear a `MISE_GITHUB_TOKEN` that was already set at the job level or exported by an earlier step. ([#658](https://github.com/jdx/mise-action/pull/658) by [@jdx](https://github.com/jdx)) #### Breaking Changes Check your workflow if a later step needs `MISE_GITHUB_TOKEN`, such as mise shims, `mise exec`, `mise run` or lazy tool installs that call the GitHub API. Those steps no longer get the token automatically and may hit GitHub API rate limits. To get the old behavior back, opt in: ```yaml - uses: jdx/mise-action@v5 with: persist_github_token: true ``` Or give later steps a separate token: ```yaml - uses: jdx/mise-action@v5 with: persist_github_token: ${{ secrets.READ_ONLY_TOKEN }} ``` **Full Changelog**: <https://github.com/jdx/mise-action/compare/v5.1.0...v5.1.1> ### [`v5.1.0`](https://github.com/jdx/mise-action/releases/tag/v5.1.0): : Tool version outputs, plugins input, and cached mise reuse [Compare Source](https://github.com/jdx/mise-action/compare/v5.0.1...v5.1.0) mise-action now reports the tool versions it installed as step outputs, can install mise plugins before tools, and can save the cache at the end of the job. Several caching fixes stop the action from downloading mise again on every run. #### Added - **Tool versions as step outputs.** After install, the action runs `mise ls --json --current` and sets a `versions` output. This is a JSON object of the active, installed tools. Each tool maps to a list of `{version, requested_version, install_path, source}` entries. Each tool also gets its own output with its resolved version, such as `steps.mise.outputs.node`. A tool only gets its own output if its name is a valid output name and isn't `cache-hit` or `versions`. Names like `npm:@scope/pkg` appear only in `versions`. If the action can't read the versions, it prints a warning and the step still succeeds. ([#655](https://github.com/jdx/mise-action/pull/655) by [@jdx](https://github.com/jdx)) ```yaml - uses: jdx/mise-action@v5 id: mise - run: echo "node ${{ steps.mise.outputs.node }}" ``` - **`plugins` input.** List plugins one per line as `name` or `name url`. Blank lines and `#` comments are ignored. The action runs `mise plugins install -y` for each one before `mise install`. Plugins that are already installed, for example restored from the cache, are left as they are. An unknown plugin fails the step. When `plugins` is set, its hash is added to the default cache key. Custom `cache_key` templates can use it as `{{plugins_hash}}`. If `plugins` is unset, existing cache keys don't change. ([#656](https://github.com/jdx/mise-action/pull/656) by [@jdx](https://github.com/jdx)) ```yaml - uses: jdx/mise-action@v5 env: # needed for idiomatic files such as .yvmrc MISE_IDIOMATIC_VERSION_FILE_ENABLE_TOOLS: yarn with: plugins: | yarn php https://github.com/verzly/mise-php#latest ``` - **`cache_save_post` input (opt-in, default `false`).** When enabled, the mise cache is saved in the action's post step instead of right after install. This way, tools installed by later steps are included in the cache, for example from monorepo sub-project configs or task-level tools. The setting only applies on a cache miss, because an existing cache entry can't be overwritten. The post step runs even if a later step fails. If the post-step save fails, the action prints a warning and the job doesn't fail. ([#649](https://github.com/jdx/mise-action/pull/649) by [@jdx](https://github.com/jdx)) - **`auto_update` input (default `false`).** See Changed below. ([#642](https://github.com/jdx/mise-action/pull/642) by [@jdx](https://github.com/jdx)) - The action now warns when you use the `mise_toml` input and a `.mise.toml` already exists in the working directory. mise loads `.mise.toml` before the `mise.toml` the action writes, so the input may have no effect. ([#654](https://github.com/jdx/mise-action/pull/654) by [@jdx](https://github.com/jdx)) #### Changed - **A cached mise is kept when `version` is unset.** Before, each new mise release made the action reject the cached binary in integrity verification and download mise again on every run until the cache key changed. Now the cached binary is kept until the cache key changes. The action verifies it against the signed checksums of the version recorded at install, without running it first. Caches saved before this release have no version record, so they are still verified against the latest release, and a tampered binary is still replaced. The integrity warning now includes the underlying error. To keep updating to newer releases as before, set `auto_update: true`. Each updated binary is cached under its own mise version, so each release is downloaded only once. An explicit `version` input works the same as before. ([#642](https://github.com/jdx/mise-action/pull/642) by [@jdx](https://github.com/jdx)) #### Fixed - **The cache is saved after a partial-match restore.** When the cache was restored from a key that only matched the prefix, the action never saved under the primary key, so it rebuilt the same tools on every run. Exact cache hits still skip the save. ([#646](https://github.com/jdx/mise-action/pull/646) by [@jdx](https://github.com/jdx)) - **Caches saved before this release no longer cause a download on every run.** These caches have no version record, so a cached binary is verified against the latest release. Once a newer mise shipped, the action downloaded mise again on every run. It now also saves the reinstalled binary in a cache keyed by mise version, so later runs restore that binary instead of downloading it. ([#648](https://github.com/jdx/mise-action/pull/648) by [@jdx](https://github.com/jdx)) - **Windows: mise installs without `unzip`.** The mise zip is now extracted with PowerShell's `Expand-Archive`. Self-hosted Windows runners that don't have `unzip`, such as fresh Windows 11 arm64 machines, can now install mise. ([#650](https://github.com/jdx/mise-action/pull/650) by [@jdx](https://github.com/jdx)) #### Documentation - New README guides cover matrix builds, using another cache action, and Rust caching: - Matrix builds: use `MISE_<TOOL>_VERSION` overrides and give each matrix entry its own `cache_key`. - Other cache actions: set `cache: false` and cache mise's data directory yourself. - Rust: explains why a restored cache can be missing Rust components such as `rustfmt`, with two workarounds. ([#654](https://github.com/jdx/mise-action/pull/654), [#651](https://github.com/jdx/mise-action/pull/651) by [@jdx](https://github.com/jdx)) **Full Changelog**: <https://github.com/jdx/mise-action/compare/v5.0.1...v5.1.0> ### [`v5.0.1`](https://github.com/jdx/mise-action/releases/tag/v5.0.1): : Verify cached mise binaries before running them [Compare Source](https://github.com/jdx/mise-action/compare/v5.0.0...v5.0.1) mise-action now checks the integrity of an already-installed `mise` binary before running it. This fixes a security issue that was reported privately. #### Fixed - **An existing `mise` binary is verified before it is run.** When a `mise` binary is already on the runner (for example, restored from cache or in `mise_dir`), the action now checks it before calling it. If you set a `sha256` input, the binary must match that checksum and report the requested version. Otherwise, it must match the signed release checksums for the version being installed. If the check fails, the action prints a warning, deletes the binary and installs the requested release again. Before this fix, the action could run a cached binary before checking it. ([#637](https://github.com/jdx/mise-action/pull/637) by [@jdx](https://github.com/jdx)) #### Changed Changes to how the action handles an existing binary, also from [#637](https://github.com/jdx/mise-action/pull/637): - **Switching versions uses a full install.** If the cached binary doesn't match the requested version, the action downloads and installs that version. It no longer runs `mise self-update`. - **Unpinned runs always pick a release.** Without a `version` input, the action now selects a release every time, using `minimum_release_age`, even when `mise` is already installed. It then checks the existing binary against that release, and reinstalls if the binary doesn't match. - **Older releases need a `sha256` input to reuse a cached binary.** Some older mise releases have no signed checksums. With the `sha256` input set, a cached binary of one of these releases can still be reused without a download. Without it, the action can't verify the binary and installs it again. **Full Changelog**: <https://github.com/jdx/mise-action/compare/v5.0.0...v5.0.1> ### [`v5.0.0`](https://github.com/jdx/mise-action/releases/tag/v5.0.0): : Default minimum release age of 24 hours for mise [Compare Source](https://github.com/jdx/mise-action/compare/v4.3.0...v5.0.0) If you don't pin a `version`, mise-action now installs the newest stable mise release that is at least 24 hours old. Upgrading mise on a runner that already has it is also less likely to hit GitHub API rate limits. #### Breaking Changes ##### `minimum_release_age` now defaults to `24h` ([#632](https://github.com/jdx/mise-action/pull/632) by [@jdx](https://github.com/jdx)) Before this release, `minimum_release_age` was an opt-in setting. It now defaults to `24h`. If you don't set `version`, the action picks the highest-numbered stable mise release published at least 24 hours ago. A mise release that just shipped won't be installed until it's a day old. To get the latest stable release right away, as in v4, set the delay to `0s`. You can also choose a longer delay: ```yaml - uses: jdx/mise-action@v5 with: minimum_release_age: 0s # or e.g. 7d ``` - An explicit `version` input still takes precedence and skips the delay. - The setting applies only to the mise binary, not to tools installed by mise. - The action now gets the release list from a public CDN index (`releases.tsv` on mise.jdx.dev) instead of paging through the GitHub Releases API. Picking a release doesn't use GitHub API quota, even when an installed binary is reused. If the index is missing or malformed, the action fails instead of skipping the release-age check. - Replacing an older installed binary still runs `mise self-update`, which may call the GitHub API to fetch that exact release. #### Fixed - `mise self-update` now runs with `MISE_GITHUB_TOKEN`. When a runner already had a different mise version installed, the action runs `mise self-update` to switch versions. That GitHub API call used to go out without authentication, so busy shared or self-hosted runners could hit the rate limit and fail with `HTTP 403 RateLimitedError`. If you already set a token in your environment, the action leaves it unchanged. ([#619](https://github.com/jdx/mise-action/pull/619) by [@hegde5](https://github.com/hegde5)) #### New Contributors - [@hegde5](https://github.com/hegde5) made their first contribution in [#619](https://github.com/jdx/mise-action/pull/619) **Full Changelog**: <https://github.com/jdx/mise-action/compare/v4.3.0...v5.0.0> </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate).

renovate-bot force-pushed renovate/https-github.com-jdx-mise-action-5.x from 4a0c2d87de to 3a0ecdced5

2026-10-04 03:17:39 +02:00

Compare

renovate-bot force-pushed renovate/https-github.com-jdx-mise-action-5.x from 3a0ecdced5 to 00091a4e72

2026-10-07 04:16:36 +02:00

Compare

renovate-bot added 1 commit 2026-10-08 03:16:27 +02:00

chore(deps): update https://github.com/jdx/mise-action action to v5

renovate/stability-days Updates have met minimum release age requirement

Details

Website build and deploy / build (pull_request) Successful in 1m7s

Details

7bbd6e55b3

renovate-bot force-pushed renovate/https-github.com-jdx-mise-action-5.x from 00091a4e72 to 7bbd6e55b3

2026-10-08 03:16:27 +02:00

Compare

All checks were successful

renovate/stability-days Updates have met minimum release age requirement

Details

Website build and deploy / build (pull_request) Successful in 1m7s

Details

You are not authorized to merge this pull request.

This pull request can be merged automatically.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin renovate/https-github.com-jdx-mise-action-5.x:renovate/https-github.com-jdx-mise-action-5.x

git checkout renovate/https-github.com-jdx-mise-action-5.x

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mxmehl/mehl.mx#32

chore(deps): update https://github.com/jdx/mise-action action to v5 #32

Release Notes

v5.1.1: : GitHub token is no longer exported to later steps by default

Fixed

Added

Breaking Changes

v5.1.0: : Tool version outputs, plugins input, and cached mise reuse

Added

Changed

Fixed

Documentation

v5.0.1: : Verify cached mise binaries before running them

Fixed

Changed

v5.0.0: : Default minimum release age of 24 hours for mise

Breaking Changes

minimum_release_age now defaults to 24h (#​632 by @​jdx)

Fixed

New Contributors

Configuration

Checkout

`v5.1.1`: : GitHub token is no longer exported to later steps by default

`v5.1.0`: : Tool version outputs, plugins input, and cached mise reuse

`v5.0.1`: : Verify cached mise binaries before running them

`v5.0.0`: : Default minimum release age of 24 hours for mise

`minimum_release_age` now defaults to `24h` (#632 by @jdx)