Build-context tar ignores the app's .dockerignore, so excluded files such as .git/config reach the build #274

New Issue

2026-10-02T07:43:10+02:00

clawbot commented

2026-10-02 07:43:10 +02:00

upaas builds an app by uploading its clone as a tar (archive.TarWithOptions(opts.ContextDir, &archive.TarOptions{}) in performBuild, internal/docker/client.go), with no exclude patterns. Docker does not filter a tar context through the app's .dockerignore: on the build host, docker build - with a tar on standard input and a build through the Docker API with BuildKit (how upaas builds) both received every file, as the review of sneak/webhooker#410 found.

So an upaas build sees a different context from docker build . on the same clone: everything an app's .dockerignore leaves out reaches the build. In particular, the version-stamping convention (sneak/project-management#21) sends .git but leaves out .git/config, which can hold a credential in the remote URL; under upaas that file reaches the builder stage's layers. upaas's own clones use a deploy key, so their URLs hold none today, but the context still differs from the app's intent.

Definition of done:

When it makes the build-context tar, upaas reads the app's .dockerignore (next to the Dockerfile it builds, as the Docker CLI does) and passes its patterns as exclude patterns, using the same pattern library the Docker CLI uses (github.com/moby/patternmatcher and its ignorefile reader), so an upaas build sees exactly the context docker build . sees.
An app without a .dockerignore builds exactly as today.
A test builds the tar for a context with a .dockerignore that excludes a file and a ! re-include, and checks which files are in it.

Model: opus-5-5

upaas builds an app by uploading its clone as a tar (`archive.TarWithOptions(opts.ContextDir, &archive.TarOptions{})` in `performBuild`, `internal/docker/client.go`), with no exclude patterns. Docker does not filter a tar context through the app's `.dockerignore`: on the build host, `docker build -` with a tar on standard input and a build through the Docker API with BuildKit (how upaas builds) both received every file, as the review of https://git.eeqj.de/sneak/webhooker/pulls/410 found. So an upaas build sees a different context from `docker build .` on the same clone: everything an app's `.dockerignore` leaves out reaches the build. In particular, the version-stamping convention (https://git.eeqj.de/sneak/project-management/issues/21) sends `.git` but leaves out `.git/config`, which can hold a credential in the remote URL; under upaas that file reaches the builder stage's layers. upaas's own clones use a deploy key, so their URLs hold none today, but the context still differs from the app's intent. Definition of done: - When it makes the build-context tar, upaas reads the app's `.dockerignore` (next to the Dockerfile it builds, as the Docker CLI does) and passes its patterns as exclude patterns, using the same pattern library the Docker CLI uses (`github.com/moby/patternmatcher` and its `ignorefile` reader), so an upaas build sees exactly the context `docker build .` sees. - An app without a `.dockerignore` builds exactly as today. - A test builds the tar for a context with a `.dockerignore` that excludes a file and a `!` re-include, and checks which files are in it. Model: opus-5-5

clawbot referenced this issue from sneak/webhooker

2026-10-02 07:43:18 +02:00

Image built by upaas stamps version "unknown" into the binary #366

clawbot referenced this issue from sneak/webhooker

2026-10-02 08:08:13 +02:00

Derive the image's version from the .git in the build context (closes #366) #410

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/upaas#274