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>
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>
CI previously re-implemented a subset of the prek hooks by hand (`cargo
test` + a bare `cargo clippy`), so `cargo fmt --check` and the stricter
`cargo clippy -- -D warnings` were enforced only by the local pre-commit
hook — easily bypassed with --no-verify (as PR #193 was). Run the same
prek suite CI-side so .pre-commit-config.yaml is the single source of
truth for what gets checked, on both commit and push.
Also drop the hard-coded `dtolnay/rust-toolchain@1.93.0` pin (which had
drifted from rust-toolchain.toml's 1.96.0) in favor of
actions-rust-lang/setup-rust-toolchain, which reads the toolchain version
and components from rust-toolchain.toml — so CI's rustfmt/clippy match
what developers run, and there is no second place to keep in sync. All
three actions are tag-pinned, so Renovate can manage them (unlike the
branch-pinned dtolnay ref).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This supersedes 7d183b9 ("Run CI for pull requests"), which mixed validation and publishing in one workflow and regressed docker-manifest by dropping the package-write permission it needs to publish the manifest.
Split the workflows so CI handles pull requests, branch pushes, tags, and manual runs, while publishing stays focused on Docker delivery with the manifest permission fixed explicitly at the job level.
