[renovate]

This PR contains the following updates:

Package	Type	Update	Change
jdx/mise-action	action	patch	v5.2.5 → v5.2.7

---

Release Notes

jdx/mise-action

v5.2.7: : Retry failed mise downloads with backoff and show the HTTP status

Compare Source

When the action can't download mise, the log now shows the HTTP status and host for each failed attempt. Retries wait longer between attempts, so a short GitHub outage is less likely to fail the job.

Fixed

• Download failures now show what went wrong, and brief outages are retried for longer. Before this release, a failed mise download logged only The process '/usr/bin/curl' failed with exit code 22 and retried five times with a fixed 2-second wait. From that message you couldn't tell a rate limit from a missing asset or a server error. Each failed attempt now logs the HTTP status and the host that answered:

  Download attempt 1/6 failed: Could not download github.com/…/mise-v2026.10.21-linux-x64.tar.zst (HTTP 503 from github.com). Retrying in 3.4 seconds.
  

  The wait between attempts doubles from about 2s up to a 30s cap, with random jitter, so the five retries cover roughly a minute. Only transient failures are retried: connection errors and timeouts, and HTTP 408, 429 and 5xx responses. A 404, any other 4xx, or a local file-write error fails at once. The log shows only the host and file name of each URL, never signed query strings or curl/wget stderr. Partial files are deleted before the next attempt. wget now runs with --tries=1, so its own 20-retry default no longer stacks on top of the action's retries. This applies to every download the action makes: the release archive, checksums and the packslip bundle. Checksum and signature verification are unchanged, and there are no new inputs. (#​722 by @​jdx, fixes #​721)

Changed

• packslip, which the action uses to verify downloaded mise releases, is updated from 1.11.0 to 1.11.2. This version includes upstream hardening of its verifier checks. (#​726)

Full Changelog: jdx/mise-action@v5.2.6...v5.2.7

v5.2.6: : Fix step hanging after a failed cache restore

Compare Source

The action now exits as soon as its work is done. Before this release, a cache restore that failed during the download could leave the step running for up to ten minutes after setup had finished.

Fixed

• A failed cache restore no longer leaves the step hanging. If the mise cache download failed partway through, for example with getaddrinfo EAI_AGAIN, the action logged a warning, installed the tools and saved the cache, then stopped producing output. The step stayed in progress until the job was cancelled or a timer inside @actions/cache fired after 10 minutes. That timer is left running when a download fails (actions/toolkit#2470), and it kept the Node process alive. The action now exits explicitly after both the main step and the post step finish. It waits up to 5 seconds for log output to flush, then exits. The exit code set by any earlier failure is kept. Errors that aren't Error objects now mark the step as failed with their message. Before, they caused an unhandled rejection. (#​718 by @​jdx and @​kjanat, fixes #​717)

Full Changelog: jdx/mise-action@v5.2.5...v5.2.6

---

Configuration

📅 Schedule: (UTC)

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