v5.2.3: Faster cache key computation in large workspaces

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: v5.2.2...v5.2.3