Skip to content

chore(deps): update jdx/mise-action action to v5.2.1 - #370

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

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

Conversation

@renovate

@renovate renovate Bot commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change OpenSSF
jdx/mise-action action minor v5.1.2 → v5.2.1 OpenSSF Scorecard

Release Notes

jdx/mise-action

v5.2.1: : Require the signed packslip for mise 2026.9.3 and later

Compare Source

The action now refuses to install mise 2026.9.3 or later if the release's signed packslip is missing. This closes a gap where verification could be downgraded to the weaker checksum check.

Fixed

  • A missing packslip no longer weakens the check on recent mise releases. v5.2.0 started checking the mise binary against the release's signed packslip.sigstore.json. If that file wasn't found, though, the action quietly fell back to the minisign-signed SHASUMS256 checksums. Anyone who could hide the file could force the weaker check. Every mise release from 2026.9.3 on includes a packslip, so for those versions a missing bundle now stops the install with an error like this:
    mise v2026.10.11 must ship a signed packslip, but https://github.com/jdx/mise/releases/download/v2026.10.11/packslip.sigstore.json was not found
    
    Releases before 2026.9.3 don't include a packslip, so they're still checked against the signed checksums. A version string that isn't three dot-separated numbers also requires a packslip. If you set the sha256 input, it still takes precedence over both checks. A packslip that fails verification still never falls back to the checksums. (#​695 by @​jdx)

Full Changelog: jdx/mise-action@v5.2.0...v5.2.1

v5.2.0: : Periodic cache rebuilds, signed packslip verification, and monorepo installs

Compare Source

The default cache key now rolls over every 30 days, so long-lived caches pick up newer mise releases. The action also checks the downloaded mise binary against the release's signed packslip, and it runs mise install --monorepo automatically in monorepos. Existing caches miss once after you upgrade, because the default cache key format has changed.

Added
  • The cache is rebuilt every 30 days by default. GitHub never evicts a cache that keeps getting hits. Before this release, an active repo could keep the same mise binary and tools for months, until a config file changed. The default cache key now includes a period suffix (-p<N>), so the cache is rebuilt from scratch at least once per period. All repos roll over on the same calendar boundary. Use the new cache_max_age_days input to change the period, or set it to 0 to keep the old key that never expires. Custom cache_key templates can use the new {{cache_period}} variable, which {{default}} already includes. A custom key that doesn't use it behaves as before. On self-hosted runners that keep mise data between runs, you may also need auto_update: true to pick up a newer mise. (#​689 by @​jdx, fixes #​688)
    - uses: jdx/mise-action@v5
      with:
        cache_max_age_days: 14 # default 30; 0 disables periodic rebuilds
  • Throttled cache restores and saves can be retried. Before this release, when GitHub's cache service returned HTTP 429, the action gave up right away: a restore counted as a miss and a save was skipped. The new cache_restore_retry_budget and cache_save_retry_budget inputs set how long the action may wait. Each retry waits for the Retry-After value plus some random jitter. Once the budget runs out, the action falls back to the old behavior. Retries apply to the main cache, the post-step save and the binary cache. Real cache misses and reservation conflicts are never retried. Both budgets default to 0s (no retries). @actions/cache doesn't report 429 errors directly, so the action detects throttling from its warning messages. If those messages change in a future @actions/cache release, throttling won't be detected and nothing will be retried. (#​692 by @​jdx, fixes #​691)
    - uses: jdx/mise-action@v5
      with:
        cache_restore_retry_budget: 60s
        cache_save_retry_budget: 120s
  • The latest mise binary can fall back to a second download source. When the action downloads the latest mise version, it can fall back between GitHub and mise.jdx.dev if the first source fails. The fetch_from_github setting decides which source it tries first. Pinned versions and minimum_release_age installs are only downloaded from GitHub. The binary is still checked against the signed checksums for the resolved version, whichever source it came from. (#​692 by @​jdx)
  • The mise binary is checked against its signed packslip. If a mise release includes packslip.sigstore.json, the action checks the downloaded binary against it. The bundle must be signed by mise's release workflow for that exact tag. After a successful check, the log shows Verified <asset> against the signed packslip. If the check fails, the install stops instead of falling back to a weaker check. Releases without a packslip use the existing minisign and SHASUMS256 check. An explicit sha256 input still takes precedence. (#​693 by @​jdx)
  • Monorepo-aware installs. If your mise config sets [monorepo].config_roots, the action now adds --monorepo to mise install, so tools configured anywhere in the monorepo get installed. Repos without that setting aren't affected. To opt out, set monorepo: false. (#​679 by @​zeitlinger)
Fixed
  • Tool directories that mise moves to the front of PATH are now exported. The action used to find mise's PATH changes by comparing mise's PATH with the runner's. If a tool's bin directory was already on the runner's PATH, such as ~/.cargo/bin, mise only moved it to the front, so the action didn't export it. Later steps then found the mise shim first. For example, rustup resolved to the shim instead of ~/.cargo/bin/rustup. The action now asks mise for its entries with mise env --paths and exports them in the order mise reports. This fix needs a mise version that supports --paths. With older versions, the action uses the old comparison. (#​685 by @​jdx)
Documentation
  • The new "Release workflows" section of the README says that jobs that publish releases shouldn't restore caches. A lower-trust workflow that can write to default-branch caches could otherwise slip files into a release. In those jobs, use cache: false or GitHub's cache-mode: none. (#​682 by @​jdx)
  • The README explains how to cache mise's downloads, keyed on mise.lock, instead of installed tools. It includes a Windows example that sets MISE_CACHE_DIR from ${{ runner.temp }}, because actions/cache doesn't expand %TEMP%. (#​686, #​690 by @​zeitlinger)
Breaking Changes
  • The default cache key has a new format, so the first run after upgrading is a cache miss and saves a fresh cache. After that, the cache is rebuilt every 30 days by default. To keep the old cache key that never expires, set cache_max_age_days: 0. Workflows that set a custom cache_key without {{default}} or {{cache_period}} aren't affected.

Full Changelog: jdx/mise-action@v5.1.2...v5.2.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 was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot changed the title chore(deps): update jdx/mise-action action to v5.2.0 chore(deps): update jdx/mise-action action to v5.2.1 Oct 19, 2026
@renovate
renovate Bot force-pushed the renovate/jdx-mise-action-5.x branch from f6a73d5 to e299a32 Compare October 19, 2026 11:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants