Skip to content

chore(deps): update jdx/mise-action action to v5.1.2 - #23

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/jdx-mise-action-5.x
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/jdx-mise-action-5.x

Conversation

@renovate

@renovate renovate Bot commented Oct 4, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
jdx/mise-action action patch v5.1.0 → v5.1.2

Release Notes

jdx/mise-action (jdx/mise-action)

v5.1.2: : mise_dir now sets MISE_DATA_DIR; auto_update handles a locked mise binary

Compare Source

The mise_dir input now also sets where mise installs tools, so those tools end up in the cache. With auto_update: true, the action no longer crashes on Windows when the mise binary is still in use.

Fixed
  • mise_dir now exports MISE_DATA_DIR. Before this release, mise_dir moved the mise binary and the cache path, but mise kept installing tools to ~/.local/share/mise. The saved cache didn't include the tools. On runners where ~/.local isn't writable, the step failed with EACCES: permission denied. When mise_dir is set, the action now exports MISE_DATA_DIR=<mise_dir>, so tools are installed into the directory that gets cached. If your workflow sets a different MISE_DATA_DIR, the mise_dir input overrides it. If mise_dir isn't set, nothing changes. mise's state directory (~/.local/state/mise) stays where it is. If that path also can't be written, set MISE_STATE_DIR yourself. (#​672 by @​jdx, fixes #​668)
    - uses: jdx/mise-action@v5
      with:
        mise_dir: ${{ runner.tool_cache }}/mise/data
  • auto_update no longer crashes when it can't replace mise.exe. On Windows, the step used to fail with a bare EPERM: operation not permitted, unlink '…\mise.exe' if another process was still using the binary. Now, if version isn't pinned and the existing binary passes verification against its recorded version, the action prints a warning and continues with that version. In any other case, the step fails with a message that says the file is in use and how to fix it. A pinned version never quietly keeps an older binary. (#​665 by @​jdx, fixes #​664)
Documentation
  • The README explains how to use mise's MISE_ENABLE_TOOLS setting as a job-level allowlist. Unlike install_args, the allowlist applies to the action's install and to later mise commands. If jobs use different allowlists, add the value to a custom cache_key. (#​667 by @​zeitlinger)
  • The Rust cache section is updated for mise 2026.9.2 and later, where mise install repairs a restored toolchain instead of leaving rustfmt missing. Swatinem/rust-cache now works alongside mise-managed Rust. (#​670 by @​jdx)

Full Changelog: jdx/mise-action@v5.1.1...v5.1.2

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: jdx/mise-action@v5.1.0...v5.1.1


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 was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested a review from a team as a code owner October 4, 2026 21:27
@renovate
renovate Bot requested review from esnunes and fortmarek and removed request for a team October 4, 2026 21:27
@renovate renovate Bot changed the title chore(deps): update jdx/mise-action action to v5.1.1 chore(deps): update jdx/mise-action action to v5.1.2 Oct 12, 2026
@renovate
renovate Bot force-pushed the renovate/jdx-mise-action-5.x branch from 896e02d to c5f41db Compare October 12, 2026 13:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants