Skip to content

chore(deps): update github actions - #1301

Merged
jaydeluca merged 1 commit into
mainfrom
renovate/github-actions
Oct 27, 2026
Merged

jaydeluca merged 1 commit into
mainfrom
renovate/github-actions

Conversation

@renovate

@renovate renovate Bot commented Oct 27, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
actions/setup-java action minor v6.0.1 → v6.1.0
github/codeql-action action minor v4.38.3 → v4.39.1
jdx/mise-action action minor v5.1.2 → v5.2.3
open-telemetry/shared-workflows workflow minor v0.19.0 → v0.24.0

Release Notes

actions/setup-java

v6.1.0

Compare Source

What's Changed
New Contributors

Full Changelog: actions/setup-java@v6.0.1...v6.1.0

github/codeql-action

v4.39.1

Compare Source

v4.39.0

Compare Source

  • Breaking change: Bump the minimum required CodeQL bundle version to 2.20.7. #​4205
  • The codeql-action/analyze step now validates that a correct argument for the checkout_path input has been provided. The checkout_path input must be set to the path where the repository that is being analyzed is checked out at on the runner, if that path is something other than the workspace root. If the path does not point to a repository checkout or is different from the path that was used by codeql-action/init, then the CodeQL Action now produces a warning. #​4148
  • Resolved an issue with third-party caching implementations that prevented caches from being restored correctly. #​4206
  • The codeql-action/start-proxy step that is used in Code Scanning Default Setup now finds CodeQL releases using the same logic as codeql-action/init. This primarily benefits customers who are using GitHub instances other than github.com where the codeql-action/start-proxy step may previously have been unable to locate recent releases and ended up using outdated versions of the private registry authentication proxy as a result. #​4198
jdx/mise-action

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

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

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

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

open-telemetry/shared-workflows

v0.24.0

Compare Source

What's Changed
New Contributors

Full Changelog: open-telemetry/shared-workflows@v0.23.0...v0.24.0

v0.23.0

Compare Source

What's Changed

Full Changelog: open-telemetry/shared-workflows@v0.22.0...v0.23.0

v0.22.0

Compare Source

What's Changed

Full Changelog: open-telemetry/shared-workflows@v0.21.0...v0.22.0

v0.21.0

Compare Source

What's Changed

Full Changelog: open-telemetry/shared-workflows@v0.20.0...v0.21.0

v0.20.0

Compare Source

What's Changed
New Contributors

Full Changelog: open-telemetry/shared-workflows@v0.19.0...v0.20.0


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • Between 12:00 AM and 07:59 AM, only on Tuesday (* 0-7 * * 2)
  • 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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • 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 review from a team as code owners October 27, 2026 04:21
@jaydeluca
jaydeluca merged commit dc871a2 into main Oct 27, 2026
17 checks passed
@jaydeluca
jaydeluca deleted the renovate/github-actions branch October 27, 2026 12:36
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.

1 participant