Catch a Dockerfile and .dockerignore disagreement on pull requests, without a daemon #140

New issue

Closed

opened 2026-08-12 10:22:41 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-12 10:22:41 +00:00

Member

Carved out of #129 and #91, which want the image built on pull requests. This is the part of that goal reachable today.

What both faults actually were

Both regressions that turned main red were the Dockerfile and .dockerignore disagreeing about one path.

#91: .dockerignore excluded docs, the build stage ran COPY docs ./docs, and sirens-echo-policy-check read docs/ during the build.
#129: .dockerignore excluded scripts/*, and the compose stage ran COPY scripts/stage-compose-sources.sh ./scripts/ for a script it then executes.

Neither needs a Docker daemon to detect. Each is a static disagreement between two tracked files in the same repository, and the test job already runs on every pull request.

Scope

A Go test that parses the Dockerfile's context COPY sources, evaluates each against the .dockerignore rules with Docker's last-match-wins and negation semantics, and fails when a copied path is excluded or missing from the tree.

The hand-maintained imageContextPaths mirror in image_context_test.go should be checked against the parsed COPY set in the same pass, since a rename can silently drift it away from what it claims to mirror.

What this does not cover

It is not the image build. A base-image change, a RUN step failure, a missing build input that is present but insufficient, or a compose-stage clone failure all still surface only after a merge.

#129 and #91 stay open for that. This narrows them to the part that needs a runner change and a first run read from the web UI, rather than leaving the whole class unguarded in the meantime.

Complete when

A .dockerignore entry that hides a copied path fails a pull-request check.
A COPY of a path the repository does not have fails a pull-request check.
Both historical faults are reproduced as cases and shown to fail.

Carved out of #129 and #91, which want the image built on pull requests. This is the part of that goal reachable today. ## What both faults actually were Both regressions that turned `main` red were the Dockerfile and `.dockerignore` disagreeing about one path. * #91: `.dockerignore` excluded `docs`, the build stage ran `COPY docs ./docs`, and `sirens-echo-policy-check` read `docs/` during the build. * #129: `.dockerignore` excluded `scripts/*`, and the compose stage ran `COPY scripts/stage-compose-sources.sh ./scripts/` for a script it then executes. Neither needs a Docker daemon to detect. Each is a static disagreement between two tracked files in the same repository, and the `test` job already runs on every pull request. ## Scope A Go test that parses the Dockerfile's context `COPY` sources, evaluates each against the `.dockerignore` rules with Docker's last-match-wins and negation semantics, and fails when a copied path is excluded or missing from the tree. The hand-maintained `imageContextPaths` mirror in `image_context_test.go` should be checked against the parsed `COPY` set in the same pass, since a rename can silently drift it away from what it claims to mirror. ## What this does not cover It is not the image build. A base-image change, a `RUN` step failure, a missing build input that is present but insufficient, or a compose-stage clone failure all still surface only after a merge. #129 and #91 stay open for that. This narrows them to the part that needs a runner change and a first run read from the web UI, rather than leaving the whole class unguarded in the meantime. ## Complete when * A `.dockerignore` entry that hides a copied path fails a pull-request check. * A `COPY` of a path the repository does not have fails a pull-request check. * Both historical faults are reproduced as cases and shown to fail.

coilyco-ops referenced this issue from a commit

2026-08-12 10:23:17 +00:00

test(image): fail a pull request when the Dockerfile and .dockerignore disagree

coilyco-ops closed this issue

2026-08-12 10:23:17 +00:00

coilyco-ops referenced this issue

2026-08-12 10:34:22 +00:00

Pull-request CI never builds the image, so Dockerfile faults only surface on main #129

coilyco-ops referenced this issue

2026-08-12 10:34:35 +00:00

ci: build the image on pull requests, not only after a merge to main #91

coilyco-ops referenced this issue