Update jdx/mr-boxington-action action to v1.4.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
jdx/mr-boxington-action	action	minor	v1.3.0 → v1.4.0

---

Release Notes

jdx/mr-boxington-action (jdx/mr-boxington-action)

v1.4.0: : Faster object-mode restores from a directory bundle

Compare Source

github-cache-mode: objects now transports the mbx bundle as a directory instead of a tar when the installed mbx is 1.12.0 or newer, cutting warm-restore import time substantially. No workflow changes are needed, but object-mode caches restore cold once after the switch.

Changed

• Object-mode caches are saved and restored as a directory bundle (#​41, @​jdx). actions/cache archives whatever path it is given, so wrapping a tar inside it meant every byte was unpacked twice on a warm restore: once by the cache action and again by mbx cache import. The post step now runs mbx cache export --format directory and the importer reads the restored tree in place. On a warm restore of a 4,071-object / 1.4 GiB closure on ubuntu-24.04, mbx cache import dropped from 6.46s to 2.02s; the cache action's own restore got about 1.3s slower because it handles ~5,000 files instead of one archive, for a net saving of roughly 3.1s before the build starts (single-trial measurements). target mode is unchanged.
  • Version-gated. --format directory arrived in mbx 1.12.0 and older binaries reject the flag, so the form follows the version actually installed. Versions below 1.12.0, and anything that does not parse as a version, keep using a tar so exports do not fail.
  • Separate cache keys. A tar entry and a directory entry cannot restore each other. Directory bundles add a -dir suffix to the generation segment of the generated key (for example linux-x64-mbx-v1-dir-rust-<hash>-<sha>), while the tar form keeps the bare generation it has always used, so entries saved before this release still restore for older mbx versions. Workflows that assert on cache-primary-key output should allow for the extra segment.
  • The job summary's Payload row now reports mbx objects (directory) or mbx objects (tar) so you can see which form a run used.

Breaking Changes

• The first object-mode job after the installed mbx crosses 1.12.0 (including version: latest picking it up automatically) restores cold once because the directory bundle uses a new cache key. Warm caches rebuild on the next default-branch save; no configuration change is required.

Full Changelog: jdx/mr-boxington-action@v1.3.1...v1.4.0

v1.3.1: : Preserve imported objects on hosted runners

Compare Source

A small release. The main change fixes cache eviction that could break object-mode caching on GitHub-hosted runners, plus a documentation cleanup.

Fixed

• Imported objects survive automatic GC on GitHub-hosted runners (#​37, @​jdx). A restored object bundle can exceed mbx's local disk budget on a GitHub-hosted runner, so automatic garbage collection could evict objects after the first build. That caused later commands to miss the cache and the post-job export to fail with action result is missing. For backend: github with github-cache-mode: objects, the action now defaults MBX_GC_AUTO=0 when RUNNER_ENVIRONMENT is github-hosted and the variable is unset, exporting it before invoking mbx so it applies for the whole job. Explicit MBX_GC_AUTO values are respected, and self-hosted/unknown runners, target mode, and other backends are unchanged. With cleanup disabled the cache can grow for the duration of the job; set MBX_GC_AUTO=1 to keep automatic cleanup, or set MBX_GC_AUTO=0 on a disposable self-hosted runner to opt into the same behavior.

Documentation

• Dropped the CI performance warning (#​32, @​jdx). Removed the README note advising that mbx does not yet consistently outperform Swatinem/rust-cache on GitHub-hosted runners; the default target payload now measures within noise on paired same-runner trials. The cache-mode section still carries the measured numbers and tradeoffs.

Full Changelog: jdx/mr-boxington-action@v1.3.0...v1.3.1

---

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.