Files
DarkRoom/docker
dtourolleandClaude Opus 5 871a0eac28
🐳 Android image / Build and push (push) Successful in 1s
Build and test / android-image (push) Successful in 1s
Build and test / Desktop (Linux) (push) Successful in 19m21s
Build and test / Layer separation (push) Successful in 29s
Traceability / Requirement traces (push) Successful in 23s
Build and test / Android (aarch64) (push) Failing after 33m3s
Check the image has the commands before CI finds out it does not
Two failures in a row were the same shape: a command the workflow calls
was not in the image. git-lfs, then file(1). Each cost a full run to
learn, and the android job is expensive to be wrong in -- the step that
fails is at the end, so every attempt paid twenty-eight minutes of
cross-compile first to reach the line that could not work.

Both were visible in ten seconds from here. `docker run <image> command -v
file` is the whole diagnosis; it just never occurred to anybody to ask
before pushing.

So the question gets asked automatically. This reads the `run:` blocks out
of the workflows, pulls the commands worth doubting -- the ones a minimal
Debian plausibly lacks, not `cd` -- and checks each against the image its
job declares. It does not run the workflow and is not a replacement for
one. It answers exactly the question that was expensive to answer.

`git lfs` is handled specially and the comment says why: it is a
subcommand, so the first word of the line is `git`, which is always there.
Taking first words alone would have missed the original bug -- and did,
in the first version of this script.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 20:31:25 +02:00
..