prek bakes the full path of the currently installed version into the hooks it
generates (var/mise/installs/prek/<version>/...). That path stops existing as
soon as the pinned version changes or old versions are pruned, and the hook's
PATH fallback finds no prek either, so every commit fails until the hook is
regenerated by hand. It also means a hook keeps running the version it was
generated with, long after mise.toml has moved on.
Rewriting PREK to mise's shim makes the hook resolve whatever mise.toml pins at
the time it runs. The accompanying MISE_DATA_DIR / MISE_TRUSTED_CONFIG_PATHS
exports keep that resolution inside this project - without them mise falls back
to the global data directory and silently installs a second copy of the tool.
The recipe becomes a shebang recipe, because just runs each line of a plain
recipe in its own shell and the patch loop needs to span several lines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It was added in 941e5f0 (2024-09-21) as a cache-less variant, because
the BuildKit cache mounts in the main Dockerfile were causing trouble in
CI, and the workflow pointed at it with `file: Dockerfile.ci`. That line
was removed in 6719538 (2025-02-27, "Switch to using native ARM64
builders"), which returned the build to the default Dockerfile - but the
file itself stayed behind.
Nothing has referenced it since. It had meanwhile drifted from the real
Dockerfile (no RELEASE_BUILD argument, no cache mounts) while Renovate
kept bumping its base image pin, so every one of those bumps was a pull
request for a file that is never built.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ci.yml runs on `push: ["**"]`, so a Renovate branch is already compiled,
linted with `clippy -D warnings` and unit-tested before anything reaches
main; a red branch makes Renovate open a pull request instead of merging.
That gate now covers the Dockerfile base too, via the build job added in
the previous commit.
Cargo, the Rust toolchain, prek and the workflows' own actions therefore
merge by branch push. The local development images under etc/services/**
do too, on a different justification recorded in the rule itself: CI does
not run them and they reach no shipped artifact, so the worst case is a
broken `just services-start`.
Majors keep their pull request - the rule is deliberately last, so it
overrides the others for every manager.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The prek job never builds an image, so a bump of the Dockerfile's base
image reached main unvalidated and only failed afterwards in Publish -
by which point ghcr.io/etkecc/baibot:latest had already been attempted.
Add a gate job that looks for Dockerfile changes against main, and a
build job that builds the image the way Publish does but with
`push: false`. The build is gated rather than unconditional because it
is a full Rust release build: running it on every push would turn a
~1 minute pipeline into a ~10 minute one for changes that cannot affect
the image. It is skipped on main, where Publish already builds.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Since mise 2026.6.4 (advisory GHSA-436v-8fw5-4mj8), trust-control settings
(`yes`, `ci`, `trusted_config_paths`, `paranoid`) in non-global configs are
ignored, and every mise invocation prints a warning about this one.
Removing it changes nothing on current mise - the setting was already dead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
