Build the container image in CI - #803
Open
ZacharyZcR wants to merge 1 commit into
Open
Conversation
Nothing has ever built docker/Dockerfile.slim in CI. It COPYs six specific files out of c/ (coli, version.py, openai_server.py, resource_plan.py, doctor.py, autotune.py) plus c/tools/, so a rename or a moved file breaks the image and only a user finds out. Same gap the .mm sources and fuzz-rans had before recent commits. The new job builds it and then runs it: `--version` and `--help` need no model and no mount, and they exercise the launcher end to end. Building is not the same as working -- a missing COPY only surfaces when the entrypoint imports something that is not in the image. Only the slim image is built, deliberately. docker/Dockerfile clones the upstream repository inside the image, which is the point of it: README's zero-setup path has the user download that single file with no checkout at all. Building it in CI would test upstream/main instead of the PR. It gets hadolint at error level instead, since it is still shipped and followed. That clone does surprise developers, though -- change something under c/, build that Dockerfile, and none of it is in the image. The README explains the two paths a few sections apart but never says this outright, so the build step now carries a note pointing at Dockerfile.slim for anyone who wants their local tree in the image. Verified locally as far as this machine allows: `coli --version` and `coli --help` exit 0 with no model and no COLI_MODEL set, which is what the image runs. The docker build itself has no local Docker daemon here, so it is the CI run on this PR that verifies it.
ZacharyZcR
marked this pull request as ready for review
August 3, 2026 21:11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft.
Nothing has ever built the container image in CI
docker/Dockerfile.slimCOPYs six specific files out ofc/(coli,version.py,openai_server.py,resource_plan.py,doctor.py,autotune.py) plusc/tools/. A rename or a moved file breaks the image and only a user finds out — the same gap*.mmandfuzz-ranshad.The new job builds it and then runs it. Building is not the same as working: a missing COPY only surfaces when the entrypoint imports something that is not in the image.
--versionand--helpneed no model and no mount, so they exercise the launcher end to end without a 372 GB bind.Only the slim image is built, deliberately
docker/Dockerfileclones the upstream repository inside the image. That is the point of it — the README's zero-setup path has the user download that one file, with no checkout at all, and build from any folder. Building it in CI would testupstream/mainrather than the PR, so it gets hadolint at error level instead. It is still shipped and still followed, so it should at least be syntactically sound.One thing that does surprise people
That clone means: change something under
c/, builddocker/Dockerfile, and none of your changes are in the image. The README describes the two paths but a few sections apart, and never says this outright. The build step now carries a note pointing atDockerfile.slimfor anyone who wants their local tree in the image.I flagged this internally as a bug first and was wrong — it is a deliberate trade for the no-checkout path. The fix is a sentence, not a rewrite.
Verification, and its limit
Verified here:
coli --versionandcoli --helpboth exit 0 with no model and withCOLI_MODELunset, which is exactly what the image runs.Not verified here: the
docker builditself. This machine has no Docker daemon (WSL without Desktop integration), so the CI run on this PR is what verifies it. If the build or the hadolint step comes back red, that is a real finding about the current Dockerfiles and I will fix it here rather than weaken the check.