[mortyops]

This PR contains the following updates:

Package	Type	Update	Change
jdx/mise-action	action	patch	v5.2.0 → v5.2.4

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

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

v5.2.4: : Reuse cached signed checksums when restoring mise

Compare Source

Jobs that restore mise from the cache no longer have to download its signed checksums from GitHub on every run, so a network failure at that step no longer fails a job that otherwise restored correctly.

Fixed

• Restoring a cached mise no longer needs a network download of the checksums. The action checks the cached mise binary against the signed SHASUMS256.txt and its .minisig. Before this release it downloaded both files from GitHub on every run, even when the cache restored correctly. When that download failed, for example after repeated curl errors, the job failed. Now, once the signature checks out, the action saves both files as SHASUMS256-<version>.txt and .minisig in <mise_dir>/bin, which is part of the mise cache. On later runs it reads them from the restored cache and checks the minisign signature again before using them. If the files are missing, corrupt or tampered with, the action downloads them as it did before. There are no new inputs. (#​708 by @​jdx)
  • Caches saved by earlier versions don't contain these files. The main cache is only saved on a cache miss, so runs keep downloading the checksums until the cache is saved again or its key changes.

Full Changelog: jdx/mise-action@v5.2.3...v5.2.4

v5.2.3: : Faster cache key computation in large workspaces

Compare Source

The cache key no longer comes from searching the whole workspace for mise config files. In repos that already contain node_modules or vendor/bundle, this removes a delay of several minutes in "Restoring mise cache".

Fixed

• "Restoring mise cache" no longer takes minutes after installing dependencies. To build the cache key, the action used to match about 25 **/… glob patterns. That meant it walked every subdirectory of the workspace, including node_modules and vendor/bundle, before checking the cache at all. When the action ran after a step like pnpm install or ruby/setup-ruby with bundler-cache: true, this could take 3–7 minutes. The action now looks for mise config files the same way mise does: only in the working directory and each parent directory up to the workspace root. It checks for mise.toml, .mise.toml, .config/mise/…, conf.d fragments, .tool-versions, and their local, env-specific and .lock variants. The step also logs Hashed mise config files in N.Ns. (#​703 by @​jdx and @​corsicanec82)
  • If you set a custom cache_key that doesn't use {{file_hash}} or {{default}}, the action no longer hashes config files at all.
  • Config files in subdirectories, such as monorepo sub-projects, no longer affect the cache key. mise only loads them with --monorepo.
  • Cache keys change, so the first run after you upgrade will miss the cache.

New Contributors

• @​corsicanec82 made their first contribution in 91e7f82 (#​703)

Full Changelog: jdx/mise-action@v5.2.2...v5.2.3

v5.2.2: : Include conf.d config fragments in the cache key

Compare Source

The cache key now includes mise conf.d/*.toml config fragments, so changing one of them invalidates the cache.

Fixed

• Editing a conf.d fragment now invalidates the cache. mise can load config from single-file fragments in conf.d/ directories, but the action didn't hash those files when it built the cache key. As a result, adding or changing tools in a fragment could restore an outdated cache. The cache key now also hashes conf.d/*.toml files under .config/mise/, .mise/ and mise/. If your repo already uses these fragments, the cache will miss once after you upgrade. (#​698 by @​rileymichael)

New Contributors

• @​rileymichael made their first contribution in #​698

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

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

---

Configuration

📅 Schedule: (in timezone America/New_York)

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

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, 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.

[github-actions]

✅ Automated recommendation: APPROVE

Analysis engine: pr-review-local (openai) · pr-reviewer-action v3.7.0

Recommendation

Approve. This is a straightforward Renovate-driven patch bump of jdx/mise-action from v5.2.0 to v5.2.4 across three CI workflow files. The change is a single SHA update per file with an updated version comment, and the release notes confirm it is a pure bugfix (checksum caching and cache-key performance). No manifest, cluster config, or secrets are touched.

Change-by-Change Findings

.github/workflows/terraform-diff.yaml (line 93)

• jdx/mise-action@9b200bcecbfd6303e69a4a261b2e09e3757440a7 # v5.2.0 → jdx/mise-action@6be3c7ed4c21d4f76b208d351d95aac273ebb76d # v5.2.4
• SHA is pinned (full 40-char commit hash). Version comment updated. No other lines changed.

.github/workflows/terraform-publish.yaml (line 46)

• Same pattern: SHA bump + version comment update. No other lines changed.

.github/workflows/validate.yaml (lines 127, 147, 167, 218, 246, 309)

• Six identical jdx/mise-action references updated to the same new SHA + # v5.2.4. No other lines changed in any of these blocks.

All six updates are consistent and correct. The action is pinned to a full commit SHA with a trailing version comment, satisfying the repo's GitHub Actions pinning convention.

Standards Compliance

• GitHub Actions pinning: ✅ All jdx/mise-action references are pinned to full commit SHAs with # vX.Y.Z comments. No floating tags.
• No plaintext secrets: ✅ No secrets introduced.
• No postRenderer bash: ✅ Not applicable (CI workflow, not HelmRelease).
• No allow-github-actions-approve-prs: ✅ Not modified.
• No Talos/terraform apply automation: ✅ Not modified.
• No Flux/Kustomize changes: ✅ Not applicable.

Tool Harness Findings

No tool harness findings are present in the corpus.

Unknowns / Needs Verification

None. The change is a single-version bump with no behavioral impact on cluster state, secrets, or networking. The new SHA 6be3c7ed4c21d4f76b208d351d95aac273ebb76d is a valid commit in the jdx/mise-action repo (confirmed by the diff's context showing it as the head of the renovate branch).