Update dependency mr-boxington to v1.19.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	Pending
mr-boxington	tools	minor	1.15.0 → 1.19.0	v1.22.0 (+3)

---

Release Notes

jdx/mr-boxington (mr-boxington)

v1.19.0: : mbx analyze, low-disk collection, and caching for CMake, build-std, and Linux cdylibs

Compare Source

The new mbx analyze command explains a slow build: it ranks the build's uncached compiler time by cause and shows the critical path. Collection now responds when free disk space runs low, and you can choose which checkouts' targets are kept and which are removed first. Standard library units from -Zbuild-std, Linux cdylib crates (including Node-API addons), and C/C++ compiles under mbx exec cmake are now cached instead of bypassed.

Added

• mbx analyze ranks a build's uncached compiler time by cause (#​569, #​568, @​jdx). The command reads the current workspace's last recorded build. It runs nothing. Where mbx explain --last gives each crate's miss separately, mbx analyze groups the misses by cause, sorts the causes by cost, and says what would remove each one. If a crate's own key didn't change but it read a changed artifact, its time is charged to the crate where the change started, through any number of levels. One edit therefore shows up as one cause, not dozens:

   47.7ms  inputs of engine changed (3)
           engine 17.1ms
           then 2 crates that depend on it rebuilt: cli 17.2ms and api 13.4ms
  

  The causes include changed inputs, changed compiler flags (counted per flag), changed environment variables, a new toolchain or linker, a first build, and each bypass reason. Bypassed compilations now record their crate and compiler time, so mbx tui no longer shows them as unnamed 0s rows. A unit is now compared only with earlier units that emitted the same outputs. This also stops mbx explain --last from blaming --emit after you switch between cargo check and cargo build. A new "Analyzing a build" docs page covers the causes and limits.

• mbx analyze shows the critical path (#​570, @​jdx). The report ends with the chain of units the build waited on, build-script runs included, and how long only one unit was running. This shows which crate or build.rs is holding the build back. It works with both Cargo build-directory layouts (up to 1.99 and 1.100+). To build this graph, mbx now records timing for more work:

  • Build-script runs are timed for the first time.
  • Timing for a bypassed rustc compilation now covers the compiler run. As a result, wrapper_phases_ns in MBX_STATS_REPORT now counts those compilations under compiler.
  • With MBX_SCHEDULER=0, the shim now waits for a bypassed compilation instead of exec-ing rustc in its place.

• Collection keeps a minimum of free disk space (#​574, @​jdx). Before, budgets were shares of total disk size and sweeps ran at most once an hour, so a disk filled by other programs, or by several agents building at once, stayed full. While a disk has less free space than gc.min_free_size:

  • Collection runs after a build as often as every 5 minutes.
  • It removes whatever is needed past the usual budgets. Learned incremental state and generated sources go first, then managed targets, least recently used first.
  • The action store stays at gc.max_size, and the most recently used target and anything a running build holds are kept.
  • If collection can't free enough, mbx logs a warning naming each disk that is still short.

  The cache disk and a separate target.root volume are each checked on their own. mbx gc applies the same rule, and mbx gc --dry-run shows the most a low disk could remove.

  [gc]
  min_free_size = "20GiB"  # default: 10% of each disk, from 5 GiB to 50 GiB; "none" turns it off

• Choose which checkouts' targets to keep or remove first (#​575, @​jdx). Both lists are empty by default.

  [target]
  keep = ["~/src/app"]                 # never collected for age or size
  evict_first = [".claude/worktrees"]  # collected first when targets are over budget

  • Kept targets are skipped by unused-unit pruning. They still count toward target.max_size, and they are still removed once their checkout is deleted.
  • Evict-first targets go first when targets are over budget or the disk is low, but the most recently used target is always spared.
  • Absolute and ~ entries cover everything at or under that directory. A relative entry matches wherever its path components appear, so .claude/worktrees covers agent worktrees in every repository.
  • When both lists match a checkout, the more specific entry wins. A tie keeps the target.
  • The environment equivalents, MBX_TARGET_KEEP and MBX_TARGET_EVICT_FIRST, take comma-separated lists.

• mbx exec cmake caches C and C++ through CMake compiler launchers (#​564, @​jdx). On a configure, mbx exec cmake now sets CMAKE_C_COMPILER_LAUNCHER and CMAKE_CXX_COMPILER_LAUNCHER. This caches two setups that were missed before: a build directory first configured without mbx, and a compiler named by full path (-DCMAKE_C_COMPILER=/usr/bin/clang, CC=gcc-13, or a toolchain file). The compiler recorded for the directory doesn't change, so there's no need to start over in a fresh build directory:

  mbx exec cmake -S . -B build     # adds launchers; existing compiler and options are kept
  mbx exec cmake --build build

  • Launchers are added only when the command after mbx exec is cmake itself running a configure, not when a script calls CMake.
  • A launcher you set yourself, with -D or in the environment, is left alone.
  • Only the Makefile and Ninja generators support launchers.
  • mbx exec cmake keeps its cache session even when no unversioned cc or gcc is on PATH.

• Host cdylib links are cached on Linux (#​579, #​580, @​jdx). C-ABI libraries and Node-API addons were bypassed as unsupported-crate-type and recompiled on every build. They now use the same native-link cache as binaries and tests. Native Linux links also accept -C link-arg=-Wl,-z,KEYWORD for defs, lazy, nodelete, nodlopen, noexecstack, norelro, now, origin, and relro, so napi-build addons (which pass -z,nodelete) are now cached too. In a 15-crate workspace with two cdylib crates, a warm build with a fresh target dropped from 3.8 s to 2.4 s. Some links still bypass:

  • cross-compiled cdylibs
  • cdylibs on macOS and Windows
  • other -z keywords, combined -Wl spellings, and -C link-args

  MBX_CACHE_LINKS=0 turns this off along with other native-link caching.

Fixed

• -Zbuild-std standard library units are cached (#​566, @​jdx). mbx now accepts the -Zforce-unstable-if-unmarked flag, so core, alloc, std, and the other standard library units are no longer bypassed as unknown-flag. RUSTC_BOOTSTRAP is now part of the cache key when it is set. Builds that set it will get one round of cache misses after upgrading. Keys for builds that don't set it are unchanged.
• mbx setup --status and mbx doctor catch a broken Cargo shim on Unix (#​576, @​jdx). The shim was reported as current even when the mbx executable it points to had been removed, for example by pruning a mise install. It is now reported as outdated, and running mbx setup repairs it.
• mbx setup explains rust-analyzer's check/overrideCommand: unexpected field warning (#​573, @​jdx). Editors show this message after setup, but checks still run through mbx. mbx setup and mbx setup --status now say so.
• The live mbx test view works on xterm terminals (#​559, @​jdx). With TERM=xterm-256color, colored test result lines were printed raw and the Tests (x/y) progress didn't advance. Both work now.

Changed

• New Mr Boxington mascot in the interactive build view (#​558, #​561, #​567, @​jdx). On terminals at least 96 columns wide, a pixel-art mascot now sits to the right of the crate list. Its lid closes as units finish, and its monocle glints on cache hits. A successful build now leaves only the summary in scrollback. A failed build leaves the knocked-over box, which now appears at the first compiler error.
• The GitHub Action docs now configure cache servers and S3 buckets with the action's backend: remote and remote-url inputs, available in mr-boxington-action v1.6.0 and later (#​557, @​jdx).

Full Changelog: jdx/mr-boxington@v1.18.0...v1.19.0

v1.18.0: : New checkouts start from another checkout's dependency units, and live target directories are pruned

Compare Source

Managed targets do more on their own in this release. With Cargo 1.100 or later, a new checkout's first build copies registry and Git dependency units that another checkout already built. Unused units are now removed from target directories that are still in use. An existing target/ is moved under the managed root without a prompt. mbx also supports Cargo 1.100's per-unit build layout and the Rust 1.99 toolchain, and a crate that reads OUT_DIR no longer recompiles on the build after it compiles.

Added

• A new checkout's first build starts from another checkout's registry units (#​550, @​jdx). Before, a fresh worktree asked the cache for every unit, one shim call at a time. That added up to seconds across a real dependency graph, and build scripts whose C output is cached only per path (aws-lc-sys, for example) compiled again in every checkout. With Cargo 1.100 or later, the first build of a profile now copies registry and Git dependency units from another checkout's managed target. Cargo treats the copies as fresh, so neither rustc nor the shim runs for them:

  $ git worktree add ../feature && cd ../feature && mbx build
  mbx[target]: copied 301 registry build units from /home/me/src/mr-boxington
  

  On a fresh clone of this repository, the first build dropped from about 13 s to about 1 s. The following limits apply:

  • Path packages are never copied, and neither is any name that a path package also uses.
  • Only units the donor profile's latest build used are copied.
  • Files are copied, which is a reflink on btrfs, XFS, and APFS, and modification times are kept. Only read-only store objects are hard-linked.
  • A unit is skipped if its symbolic links or recorded build-script output point into the other checkout.
  • The step is skipped if either checkout's Cargo lock is busy.

  On by default. Turn it off with MBX_TARGET_SEED=0 or:

  [target]
  seed = false

• Unused build units are removed from live managed target directories (#​549, @​jdx). Before, a managed target was collected only when its checkout was deleted, when it aged out, or when the size budget needed space. A checkout in daily use kept every unit it had ever built, across every Cargo.lock, feature, and toolchain change. Collection now also removes units that no build has used for target.max_age (30 days by default) plus one day. To decide which units are unused, mbx reads the access times of Cargo's fingerprint files.

  • Under Cargo 1.100 or later, each unit directory is removed on its own.
  • Under earlier Cargo, the old deps/, .fingerprint/, and build/ layout is removed as a whole once no build has used any of it. This frees a checkout's old outputs after it moves to Cargo 1.100.
  • Unused units are removed before the size budget is checked.
  • The pass is skipped on filesystems that do not record access times (for example noatime mounts, and often NTFS), and for targets that a build is using.
  • Setting target.max_age = "none" keeps all units.

  mbx gc reports the removal on its own line (removed <count> unused build units from live target directories). mbx gc --json adds targets.removed_units and targets.removed_unit_bytes.

Changed

• An existing target/ is adopted on the first build without a prompt (#​545, @​jdx). Before, a checkout that already had a real target/ stayed unmanaged unless you ran mbx adopt or accepted a prompt in a terminal. Builds run by agents, scripts, and editors never saw the prompt, so their directories were never collected. Now any mbx build outside CI moves the existing target/ under the managed root when a same-filesystem rename is possible, and keeps every output:

  • CI builds are never moved, so cache steps that save target/ keep working.
  • Directories set with --target-dir, CARGO_TARGET_DIR, or build.target-dir are never moved.
  • If the managed root is on another filesystem, the behavior is unchanged: an interactive build still offers to remove the old outputs, with "Keep it" as the default.
  • If Cargo is writing to the directory, the move is retried on a later build.
  • The first mbx build after moving a target/ that plain Cargo built may recompile some crates.

  To keep every target/ where Cargo puts it, set target.views = false (or MBX_TARGET_VIEWS=0).

• Cache hashing and prefetch planning are faster (#​538, #​539, #​541, #​542, #​543, #​544, #​546, #​547, @​jdx). C/C++ and assembler inputs are hashed faster: scanning for timestamp macros takes up to 79% less time on large headers. Prefetch ranking skips parsing full prediction payloads and was 6-7 times faster in synthetic benchmarks. These are component measurements, not whole-build speedups.

• The Get started guide now includes a prompt you can give a coding agent to set up mbx (#​540). The comparison page was rewritten to help new users choose between mbx, kache, sccache, CI caches, and incremental compilation (#​537).

Fixed

• Cargo 1.100 and Rust 1.99 support (#​548, @​jdx).
  • Under Cargo 1.100's per-unit layout, every package with a build script got its own pinned copy of the mbx binary (a full copy on macOS). All build-script launchers now share one pinned binary per profile again.
  • Standalone rustc invocations now map the whole target directory, not just the unit's own out/, so their cache keys work across checkouts.
  • Linker selection now handles Cargo 1.99's built-in debug profile and cargo install:
    • The debug profile (used by cargo install --debug) uses [linker.profiles.dev] unless [linker.profiles.debug] exists.
    • cargo install without --debug now uses [linker.profiles.release]. Before, it looked up dev.
• A crate that reads OUT_DIR (for example through include!(concat!(env!("OUT_DIR"), ...))) no longer recompiles on the next no-change build, along with every crate that depends on it (#​551, @​jdx). The copies mbx makes of build-script output now keep the original modification times, so Cargo no longer treats them as newer than the unit.
• Plain build output (piped or captured stderr, or MBX_DISPLAY=plain) no longer prints the seven-line mascot before every build (#​533, @​jdx). The mbx[progress] lines and the mbx[cache] summary are unchanged. The animated terminal view still shows the mascot.

Full Changelog: jdx/mr-boxington@v1.17.0...v1.18.0

v1.17.0: : Memory-pressure-aware compile scheduling and build-script replay for custom build paths

Compare Source

The machine-wide scheduler now watches live memory pressure and stops admitting new compilers while the machine is short on memory, with an opt-in Linux mode that can freeze running compiler trees in delegated cgroups. Build scripts declared with a custom build = "..." path (aws-lc-sys, for example) are now replayed from the cache instead of rerunning on every build, and crates that merely look like build scripts are no longer mistaken for them.

Added

• Admission control reacts to live memory pressure (#​520, #​521, @​jdx). Until now the pool admitted compilers based on permits and recorded memory estimates, so several concurrent builds could still push a machine into swap when cold compilations had no history. mbx now samples pressure at most every 500 ms and, after two unhealthy samples, defers new admissions, including compilations with no memory estimate, until five healthy seconds pass; admissions then ramp back up over five seconds. Linux uses available-memory headroom plus full-memory PSI stalls from the host and visible cgroup v2 ancestors; macOS uses headroom only. Running compilers are never paused by this setting, an idle pool always lets one compilation start, and probe failures fall back to the previous permit and estimate checks. On by default; opt out with:

  MBX_SCHEDULER_PRESSURE=0 mbx build

  or pressure = false under [scheduler]. scheduler.memory = "none" or MBX_SCHEDULER=0 also disables it.

• Experimental: suspend compiler trees under pressure in delegated Linux cgroups (#​523, #​525, @​jdx). When admission control alone is not enough, opted-in Linux builds place each eligible rustc, GCC, or Clang invocation and its descendants (including linkers) in its own cgroup. After pressure persists for two seconds mbx freezes the newest eligible compiler, at most one per second, while the oldest keeps running; on recovery, frozen work resumes oldest first before anything new is admitted. Frozen compilers keep their permits. Off by default and only settable from the environment or the global config, never from a repository .mbx.toml:

  [scheduler]
  suspend = true
  cgroup_root = "/sys/fs/cgroup/my-delegated-builds"

  (MBX_SCHEDULER_SUSPEND=1, MBX_SCHEDULER_CGROUP_ROOT=...). cgroup_root must be an absolute, writable, delegated cgroup v2 directory; pressure control and memory scheduling must be enabled. mbx does not provision delegation or change host memory limits, and if delegation is unavailable or the platform is unsupported it warns once per session and continues with admission-only scheduling. Freezing retains allocated memory, so it cannot rescue a compilation that is too large to run alone, and mbx never kills and retries a compilation. Custom compiler wrappers, build-script binaries, test binaries, and compilers nested inside a supervised compiler are excluded. A supervisor and an independent watchdog run outside the compiler cgroups and thaw everything if either dies or hangs. Suspension events and per-action statistics are written under scheduler/supervision-*/ in the cache directory, and compiler completion reports time spent suspended.

Fixed

• Build scripts with a custom build path are now replayed from the cache (#​526, @​jdx). mbx only recognized scripts compiled from build.rs (crate build_script_build), so a package such as aws-lc-sys with build = "builder/main.rs" ran its build script in full on every build even on a cache hit, recompiling and archiving its C sources for about 3.5 seconds on the critical path of everything depending on it (reqwest, rustls, and other aws-lc-rs users). Any Cargo build script is now replayed regardless of its source file name. On the jdx/hk benchmark, a warm store with a fresh target went from 4.58 s to 1.02 s. Builds into a different target path than the one that filled the cache still rerun aws-lc-sys's script, because its C objects are cached per target path, as before.

• Crates that only look like build scripts are no longer treated as one (#​528, @​jdx). A [[bin]] target named build-script-build had its executable replaced with the build-script launcher, so running target/debug/build-script-build failed with exec: .../.mbx-build-script-shims/.../mbx: not found. With native-link caching off (MBX_CACHE_LINKS=0), libraries named like build scripts (for example build-script-helper) went through the execution-only path and recompiled every build. mbx now recognizes a build script only when Cargo is building one: a build_script_* crate whose only --crate-type is bin and for which CARGO_BIN_NAME is unset. The check works under both Cargo's current target layout and the build-dir layout Cargo 1.100 makes the default, and it reads arguments after expanding @argfile response files, so build scripts whose arguments arrive that way are cached too.

For library users, mbx-cache-rustc 0.18.1 carries the same change: RustcOutputs::build_script_executable now keys off the build-script crate name alone rather than the build/ output directory, and callers are expected to confirm with Cargo's environment as mbx does.

Full Changelog: jdx/mr-boxington@v1.16.0...v1.17.0

v1.16.0: : Hard-linked restores on ext4, opt-in cargo test scheduling, and fixes for multiple mbx installations

Compare Source

Cache hits on filesystems that cannot clone files (ext4 above all) now hard link the stored object instead of copying every byte, native .a archives produced by build scripts no longer change digest on every build because of an ar timestamp, and cargo test binaries can optionally take permits from the machine-wide scheduler. Several fixes cover machines that run more than one mbx installation, including CI runners where per-job installs share one cache directory.

Added

• cargo test binaries can run under the machine-wide permit pool (#​513, @​jdx). mbx already keeps simultaneous builds from oversubscribing the machine, but only for compiler processes; several cargo test runs reaching their test phase together (for example, coding agents in separate worktrees) each still started a thread per CPU. With the new opt-in scheduler.tests setting, mbx installs itself as Cargo's target runner and each test binary waits for permits before it starts, then runs through whatever runner was configured before (qemu, a wrapper script). Off by default; enable it in .mbx.toml or your global config, or per run:

  [scheduler]
  tests = true

  MBX_SCHEDULER_TESTS=1 mbx test --workspace

  A binary's first run asks for --test-threads=N / RUST_TEST_THREADS=N permits if stated, otherwise half the pool; after a complete run of at least a second, mbx records its measured average core usage (Unix only) and later runs ask for that many. Nested builds a test starts (trybuild, compile-fail suites) run with scheduling off and count against the test's permits. --no-run, --list, doctests, and commands with --config, -C, --directory, or +toolchain are not wrapped. Also in this change: runner environment keys now turn . into _ as Cargo does, which affects cargo run with custom target names containing a dot.

• Private compiler shim directories for containers sharing a cache (#​501, @​jbellis). When several containers share MBX_CACHE_DIR but each has its own mbx binary, one container could repoint the shared compiler symlinks at a binary that exists only in its own filesystem, and the others failed with exit 127. The new shims_dir setting (MBX_SHIMS_DIR) puts the persistent Rust, C/C++, cross-compiler, CMake, and mbx exec shims in a private directory while build artifacts stay shared:

  MBX_CACHE_DIR=/shared/mbx MBX_SHIMS_DIR=/var/lib/worker/mbx-shims mbx build

  The default remains <cache_dir>/shims. Absolute paths are used as given; relative paths resolve beneath cache_dir and are rejected if they traverse above it or normalize to an empty path. The directory must persist across builds and contain no real compilers. Existing CMake trees that recorded an old shim path need reconfiguring (for example mbx exec cmake --fresh -S . -B build). This is a global or environment setting, not a workspace policy.

Changed

• Restores hard link cached outputs where the filesystem cannot clone them (#​511, #​514, @​jdx). Restores previously tried a reflink and fell back to a byte copy, so on ext4 (most Linux CI runners) every restored byte was written: a warm build of jdx/hk copied 1.32 GB across 1565 files. The order is now reflink, then a hard link to the stored object, then a copy. Filesystems with clone support (APFS, Btrfs, XFS with reflink, ZFS) are unaffected. A hard-linked output is the store's object, so it is read-only; mbx unlinks it before a compiler rewrites it, so rebuilding through mbx works as before, but running plain cargo directly in a target directory mbx filled can report output file ... is not writeable for a unit it decides to rebuild. Set restore_hardlink = false (or MBX_RESTORE_HARDLINK=0) to keep every restored output a private writable copy. mbx doctor replaces its reflink check with a restore check that reports whether a given cache and target directory pair clones, hard links, or copies, and the session summary and MBX_STATS_REPORT gain hardlinked_output_files and hardlinked_output_bytes next to the reflinked and copied counters.

• Native archive timestamps no longer miss every downstream cached action (#​506, @​jdx). Apple's ar and ranlib stamp the current time into an archive, so a build script producing a .a (CMake-based -sys crates in particular, which call /usr/bin/ar directly) handed Cargo a different digest on every build even when nothing changed; one surveyed cache held libz-ng.a under 7 digests for 7 byte-identical member sets. mbx now sets ZERO_AR_DATE for the build scripts it runs, controlled by the new ar_determinism setting (MBX_AR_DETERMINISM): auto (default) normalizes every profile except release, always covers release too, and off leaves the toolchain alone. A ZERO_AR_DATE you set yourself always wins. The effective value is part of the build-script action key and the action version was bumped, so existing build-script entries are recomputed once after upgrading. mbx doctor gains an archives check that probes the local tools and reports what the configured policy does about them.

Fixed

• Nested Cargo builds inside tests write to their own target directory (#​502, @​stewartadam). mbx used to inject CARGO_TARGET_DIR for its managed target placement, and tests inherited it, so a test that ran cargo build on a separate guest crate found the guest's artifacts in the parent project's target/ instead of guest/target/. Placement is now passed to Cargo as an invocation-local --config build.target-dir=..., so tests and build scripts see only the CARGO_TARGET_DIR the caller set, if any, and their nested builds resolve their own target directories.

• Multiple mbx installations no longer break each other's C builds (#​516, #​504, #​517, @​jdx). Three related defects, all reachable with two mbx binaries on one machine:

  • Installations sharing a cache directory (concurrent CI jobs on a self-hosted runner with per-job tool installs) all pointed HOST_CC/HOST_CXX at one shared <cache>/shims/mbx-c symlink, repointed by whichever session started last; when that job's install directory was cleaned up, every other running build failed with failed to find tool "/var/cache/mbx/shims/mbx-c": No such file or directory (discussion #​515). Session C, C++, and CMake shims now live under <shims_dir>/native/<install id>/, keyed by the mbx binary's path, so each installation owns its own. An in-place upgrade on Unix keeps the same paths; a different install path gets new ones, so cc-rs build scripts re-run once and existing CMake trees in OUT_DIR are moved to the new launcher automatically.
  • Two installations could each resolve the other's cc shim as "the real compiler" and hand a compilation back and forth until the machine ran out of processes, with no object file and no diagnostic. mbx now writes a .mbx-shims marker into every directory it installs shims in and skips marked directories when looking for a real compiler, including pins recorded by an older mbx. Do not point shims_dir at a directory that also holds real compilers, since mbx will then skip it.
  • Every in-place upgrade left behind a rust/<id> RUSTC_WRAPPER directory that was never collected (one machine had 206). Sessions now hold a lease on their wrapper directory, and on Unix each session start removes native/ and rust/ directories that no session has used for 7 days and no running session leases, or whose links all dangle. Directories left by versions before this release are removed only once their links dangle; delete older piles by hand. Windows shims are never collected.

• Automatic cache cleanup works when mbx is installed as a hard link named cargo (#​505, @​jbellis). The detached collector launched that executable with gc --automatic, re-entered Cargo-shim mode, and failed with error: no such command: gc, leaving an over-budget cache uncollected.

• Target directory collection no longer removes a view a build just claimed (#​512, @​jdx). The two-second grace window that protects a checkout whose build started during a sweep was measured from the wall clock at each check rather than from the sweep's start, so a slow sweep narrowed its own window. It now uses one timestamp for the whole sweep; a slow sweep can only widen the window.

Library changes

mbx-cache-core 0.18.0 adds hardlinked_output_files and hardlinked_output_bytes to RestoreStats and AgentStats (#​514). This is a semver break for embedders that construct those structs with literals. The shim-agent AGENT_PROTOCOL_VERSION moves to 10; since the shim and agent already require an exact version match, nothing that interoperated before stops doing so. The mbx-cache-protocol remote-cache wire contract is unchanged.

New Contributors

• @​stewartadam made their first contribution in #​502

Full Changelog: jdx/mr-boxington@v1.15.0...v1.16.0

---

Configuration

📅 Schedule: (in timezone Asia/Tokyo)

• Branch creation
  • Only on Monday (* * * * 1)
• 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.