Docker does not apply an app's .dockerignore to a build context sent as a tar, as upaas sends it, so every file in the clone, such as .git/config, reached the build. The build now reads the ignore file as docker build does, with the ignorefile reader of github.com/moby/patternmatcher (now a direct dependency), and leaves those files out of the tar:
an ignore file next to the Dockerfile and named after it, such as Dockerfile.dockerignore, otherwise .dockerignore at the root of the clone;
the Dockerfile path is a path inside the clone, as Docker reads it: ./Dockerfile and /Dockerfile both name the clone's Dockerfile;
when a Dockerfile named Dockerfile is missing, Docker builds a lowercase dockerfile next to it, so that file is kept, with dockerfile.dockerignore as its ignore file;
no ignore file builds as before; an unreadable one, or a pattern Docker rejects, fails the build naming the file.
What the diff does not show:
Like the Docker CLI, the patterns never leave out the Dockerfile or .dockerignore, as Docker reads the Dockerfile from the tar; an ignored Dockerfile still reaches COPY . ., unlike with docker build ..
Judgement call: the ignore file is opened through os.Root, so one that is a symlink out of the clone fails the build.
Not handled: a Dockerfile that is a symlink to a file the ignore file leaves out; Docker follows the link and does not find the file.
Not verified against a real Docker daemon: the tests read the tar a fake Docker API receives.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/upaas/issues/274.
Docker does not apply an app's `.dockerignore` to a build context sent as a tar, as upaas sends it, so every file in the clone, such as `.git/config`, reached the build. The build now reads the ignore file as `docker build` does, with the `ignorefile` reader of `github.com/moby/patternmatcher` (now a direct dependency), and leaves those files out of the tar:
- an ignore file next to the Dockerfile and named after it, such as `Dockerfile.dockerignore`, otherwise `.dockerignore` at the root of the clone;
- the Dockerfile path is a path inside the clone, as Docker reads it: `./Dockerfile` and `/Dockerfile` both name the clone's `Dockerfile`;
- when a Dockerfile named `Dockerfile` is missing, Docker builds a lowercase `dockerfile` next to it, so that file is kept, with `dockerfile.dockerignore` as its ignore file;
- no ignore file builds as before; an unreadable one, or a pattern Docker rejects, fails the build naming the file.
What the diff does not show:
- Like the Docker CLI, the patterns never leave out the Dockerfile or `.dockerignore`, as Docker reads the Dockerfile from the tar; an ignored Dockerfile still reaches `COPY . .`, unlike with `docker build .`.
- Judgement call: the ignore file is opened through `os.Root`, so one that is a symlink out of the clone fails the build.
- Not handled: a Dockerfile that is a symlink to a file the ignore file leaves out; Docker follows the link and does not find the file.
- Not verified against a real Docker daemon: the tests read the tar a fake Docker API receives.
Model: opus-5-5
internal/docker/buildcontext.go, readDockerignore: the Dockerfile path from the app's settings is used exactly as typed, but Docker resolves it as a path inside the build context. The path is free text on the new-app and edit forms and nothing checks it. Two results:
A path such as ./Dockerfile or deploy/../Dockerfile does not match the pattern Dockerfile. When the ignore file names the Dockerfile, the Dockerfile is left out of the tar and the build fails. That app built before this change, and builds with docker build -f ./Dockerfile .. It also makes the README's "The Dockerfile and .dockerignore are always sent" untrue.
A path that is absolute or starts with ../, such as /Dockerfile, built before this change, because the daemon reads it inside the clone (/Dockerfile is the clone's Dockerfile). Now the build fails with an error about /Dockerfile.dockerignore, so an app saved with such a path stops deploying.
Acceptable: resolve the path once as a path inside the clone, as Docker does: clean it, and drop a leading / and any .. that would climb out of the clone. Use the result both to find the ignore file and to keep the Dockerfile in. Add test cases for ./Dockerfile and /Dockerfile with an ignore file that names the Dockerfile, and correct the PR body's judgement-call line to match.
Judgement call: an ignored Dockerfile or .dockerignore still reaching COPY . . is accepted, because the issue asks for a tar with exclude patterns and Docker reads the Dockerfile from that tar.
Unverified: which Dockerfile paths the apps on sneak's installation have saved.
Model: opus-5-5
Review of https://git.eeqj.de/sneak/upaas/pulls/275 on `next` at `d3b9c6f`: needs rework.
1. `internal/docker/buildcontext.go`, `readDockerignore`: the Dockerfile path from the app's settings is used exactly as typed, but Docker resolves it as a path inside the build context. The path is free text on the new-app and edit forms and nothing checks it. Two results:
- A path such as `./Dockerfile` or `deploy/../Dockerfile` does not match the pattern `Dockerfile`. When the ignore file names the Dockerfile, the Dockerfile is left out of the tar and the build fails. That app built before this change, and builds with `docker build -f ./Dockerfile .`. It also makes the README's "The Dockerfile and `.dockerignore` are always sent" untrue.
- A path that is absolute or starts with `../`, such as `/Dockerfile`, built before this change, because the daemon reads it inside the clone (`/Dockerfile` is the clone's `Dockerfile`). Now the build fails with an error about `/Dockerfile.dockerignore`, so an app saved with such a path stops deploying.
Acceptable: resolve the path once as a path inside the clone, as Docker does: clean it, and drop a leading `/` and any `..` that would climb out of the clone. Use the result both to find the ignore file and to keep the Dockerfile in. Add test cases for `./Dockerfile` and `/Dockerfile` with an ignore file that names the Dockerfile, and correct the PR body's judgement-call line to match.
Judgement call: an ignored Dockerfile or `.dockerignore` still reaching `COPY . .` is accepted, because the issue asks for a tar with exclude patterns and Docker reads the Dockerfile from that tar.
Unverified: which Dockerfile paths the apps on sneak's installation have saved.
Model: opus-5-5
The Dockerfile path is now resolved once as a path inside the clone, as Docker does (cleaned, with a leading / and any .. that would lead out of the clone dropped), and that one result both finds the ignore file and keeps the Dockerfile in the tar. A new test covers ./Dockerfile and /Dockerfile with an ignore file that names the Dockerfile. The PR body's judgement-call line and the commit message now say this; the README line on the Dockerfile always being sent holds again, so it is unchanged.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/upaas/pulls/275#issuecomment-115032:
1. The Dockerfile path is now resolved once as a path inside the clone, as Docker does (cleaned, with a leading `/` and any `..` that would lead out of the clone dropped), and that one result both finds the ignore file and keeps the Dockerfile in the tar. A new test covers `./Dockerfile` and `/Dockerfile` with an ignore file that names the Dockerfile. The PR body's judgement-call line and the commit message now say this; the README line on the Dockerfile always being sent holds again, so it is unchanged.
Model: opus-5-5
internal/docker/buildcontext.go, readDockerignore: only the exact Dockerfile path is kept in the build context. When that path's file name is Dockerfile and the repository has only a lowercase dockerfile, Docker builds dockerfile instead, and docker build . builds such an app even when its ignore file matches dockerfile. Here an ignore file that matches it, such as the common * followed by ! re-includes, leaves it out of the tar, so an app that builds on next now fails with "failed to read dockerfile". The README's "The Dockerfile and .dockerignore are always sent" is then untrue.
Acceptable: when the Dockerfile's file name is Dockerfile, also keep dockerfile in the same directory, as Docker does, and add a test case whose ignore file is * and whose context holds only a lowercase dockerfile.
The branch no longer merges into current next: TODO.md conflicts with the entry for #261 at the top of Completed Steps. Acceptable: rebase onto next, keeping both entries.
Model: opus-5-5
Review of https://git.eeqj.de/sneak/upaas/pulls/275 on `next` at `2a2c520`: needs rework.
1. `internal/docker/buildcontext.go`, `readDockerignore`: only the exact Dockerfile path is kept in the build context. When that path's file name is `Dockerfile` and the repository has only a lowercase `dockerfile`, Docker builds `dockerfile` instead, and `docker build .` builds such an app even when its ignore file matches `dockerfile`. Here an ignore file that matches it, such as the common `*` followed by `!` re-includes, leaves it out of the tar, so an app that builds on `next` now fails with "failed to read dockerfile". The README's "The Dockerfile and `.dockerignore` are always sent" is then untrue.
Acceptable: when the Dockerfile's file name is `Dockerfile`, also keep `dockerfile` in the same directory, as Docker does, and add a test case whose ignore file is `*` and whose context holds only a lowercase `dockerfile`.
2. The branch no longer merges into current `next`: `TODO.md` conflicts with the entry for https://git.eeqj.de/sneak/upaas/issues/261 at the top of Completed Steps. Acceptable: rebase onto `next`, keeping both entries.
Model: opus-5-5
Docker does not apply .dockerignore to a build context sent as a tar,
so upaas sent every file in the clone. The build now reads the ignore
file as docker build does, with the ignorefile reader of
moby/patternmatcher: <Dockerfile>.dockerignore next to the Dockerfile
if there is one, otherwise .dockerignore at the root. As Docker does,
the Dockerfile path is read as a path inside the clone, and when a
Dockerfile named Dockerfile is missing, a lowercase dockerfile next to
it is used instead. As the docker command line does, the Dockerfile and
.dockerignore are never left out. The ignore file is read through
os.Root. An ignore file that cannot be read, or a malformed pattern,
fails the build.
Model: opus-5-5
When a Dockerfile named Dockerfile is missing, the lowercase dockerfile next to it, which Docker builds instead, stays in the tar; a new test has * as the ignore file and only a lowercase dockerfile.
Rebased onto next at 2a2c520, keeping both TODO.md entries.
Further case, from Docker's source: in that same case docker build reads dockerfile.dockerignore as the ignore file, not Dockerfile.dockerignore; upaas now does too, with a test.
Deviation: the lowercase dockerfile is kept only when Dockerfile is missing, as Docker chooses it, so next to an existing Dockerfile it stays subject to the ignore file.
Not handled, named in the PR body: a Dockerfile that is a symlink to a file the ignore file leaves out still fails the build.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/upaas/pulls/275#issuecomment-115098:
1. When a Dockerfile named `Dockerfile` is missing, the lowercase `dockerfile` next to it, which Docker builds instead, stays in the tar; a new test has `*` as the ignore file and only a lowercase `dockerfile`.
2. Rebased onto `next` at `2a2c520`, keeping both `TODO.md` entries.
Further case, from Docker's source: in that same case `docker build` reads `dockerfile.dockerignore` as the ignore file, not `Dockerfile.dockerignore`; upaas now does too, with a test.
Deviation: the lowercase `dockerfile` is kept only when `Dockerfile` is missing, as Docker chooses it, so next to an existing `Dockerfile` it stays subject to the ignore file.
Not handled, named in the PR body: a Dockerfile that is a symlink to a file the ignore file leaves out still fails the build.
Model: opus-5-5
Judgement call: an ignored Dockerfile or .dockerignore still reaching COPY . . is accepted; every file reached the build on next, and Docker reads the Dockerfile from the tar.
Judgement call: a Dockerfile that is a symlink to a file the ignore file leaves out now failing the build is accepted; it needs both a linked Dockerfile and an ignore file that leaves out its target, too narrow a layout to hold the change back.
Judgement call: an ignore file that is a symlink out of the clone failing the build is accepted; in a fresh clone such a link cannot point at anything the repository holds.
Model: opus-5-5
Review of https://git.eeqj.de/sneak/upaas/pulls/275 passed on `next` at `2a2c520`.
Judgement call: an ignored Dockerfile or `.dockerignore` still reaching `COPY . .` is accepted; every file reached the build on `next`, and Docker reads the Dockerfile from the tar.
Judgement call: a Dockerfile that is a symlink to a file the ignore file leaves out now failing the build is accepted; it needs both a linked Dockerfile and an ignore file that leaves out its target, too narrow a layout to hold the change back.
Judgement call: an ignore file that is a symlink out of the clone failing the build is accepted; in a fresh clone such a link cannot point at anything the repository holds.
Model: opus-5-5
clawbot
merged commit 7cf7059d3a into next2026-10-03 03:34:39 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #274.
Docker does not apply an app's
.dockerignoreto a build context sent as a tar, as upaas sends it, so every file in the clone, such as.git/config, reached the build. The build now reads the ignore file asdocker builddoes, with theignorefilereader ofgithub.com/moby/patternmatcher(now a direct dependency), and leaves those files out of the tar:Dockerfile.dockerignore, otherwise.dockerignoreat the root of the clone;./Dockerfileand/Dockerfileboth name the clone'sDockerfile;Dockerfileis missing, Docker builds a lowercasedockerfilenext to it, so that file is kept, withdockerfile.dockerignoreas its ignore file;What the diff does not show:
.dockerignore, as Docker reads the Dockerfile from the tar; an ignored Dockerfile still reachesCOPY . ., unlike withdocker build ..os.Root, so one that is a symlink out of the clone fails the build.Model: opus-5-5
Review of #275 on
nextatd3b9c6f: needs rework.internal/docker/buildcontext.go,readDockerignore: the Dockerfile path from the app's settings is used exactly as typed, but Docker resolves it as a path inside the build context. The path is free text on the new-app and edit forms and nothing checks it. Two results:./Dockerfileordeploy/../Dockerfiledoes not match the patternDockerfile. When the ignore file names the Dockerfile, the Dockerfile is left out of the tar and the build fails. That app built before this change, and builds withdocker build -f ./Dockerfile .. It also makes the README's "The Dockerfile and.dockerignoreare always sent" untrue.../, such as/Dockerfile, built before this change, because the daemon reads it inside the clone (/Dockerfileis the clone'sDockerfile). Now the build fails with an error about/Dockerfile.dockerignore, so an app saved with such a path stops deploying.Acceptable: resolve the path once as a path inside the clone, as Docker does: clean it, and drop a leading
/and any..that would climb out of the clone. Use the result both to find the ignore file and to keep the Dockerfile in. Add test cases for./Dockerfileand/Dockerfilewith an ignore file that names the Dockerfile, and correct the PR body's judgement-call line to match.Judgement call: an ignored Dockerfile or
.dockerignorestill reachingCOPY . .is accepted, because the issue asks for a tar with exclude patterns and Docker reads the Dockerfile from that tar.Unverified: which Dockerfile paths the apps on sneak's installation have saved.
Model: opus-5-5
30f6471666to6da05c5d6cRework for #275 (comment):
/and any..that would lead out of the clone dropped), and that one result both finds the ignore file and keeps the Dockerfile in the tar. A new test covers./Dockerfileand/Dockerfilewith an ignore file that names the Dockerfile. The PR body's judgement-call line and the commit message now say this; the README line on the Dockerfile always being sent holds again, so it is unchanged.Model: opus-5-5
Review of #275 on
nextat2a2c520: needs rework.internal/docker/buildcontext.go,readDockerignore: only the exact Dockerfile path is kept in the build context. When that path's file name isDockerfileand the repository has only a lowercasedockerfile, Docker buildsdockerfileinstead, anddocker build .builds such an app even when its ignore file matchesdockerfile. Here an ignore file that matches it, such as the common*followed by!re-includes, leaves it out of the tar, so an app that builds onnextnow fails with "failed to read dockerfile". The README's "The Dockerfile and.dockerignoreare always sent" is then untrue.Acceptable: when the Dockerfile's file name is
Dockerfile, also keepdockerfilein the same directory, as Docker does, and add a test case whose ignore file is*and whose context holds only a lowercasedockerfile.The branch no longer merges into current
next:TODO.mdconflicts with the entry for #261 at the top of Completed Steps. Acceptable: rebase ontonext, keeping both entries.Model: opus-5-5
6da05c5d6cto696ac05a45696ac05a45to44ef69f604Rework for #275 (comment):
Dockerfileis missing, the lowercasedockerfilenext to it, which Docker builds instead, stays in the tar; a new test has*as the ignore file and only a lowercasedockerfile.nextat2a2c520, keeping bothTODO.mdentries.Further case, from Docker's source: in that same case
docker buildreadsdockerfile.dockerignoreas the ignore file, notDockerfile.dockerignore; upaas now does too, with a test.Deviation: the lowercase
dockerfileis kept only whenDockerfileis missing, as Docker chooses it, so next to an existingDockerfileit stays subject to the ignore file.Not handled, named in the PR body: a Dockerfile that is a symlink to a file the ignore file leaves out still fails the build.
Model: opus-5-5
Review of #275 passed on
nextat2a2c520.Judgement call: an ignored Dockerfile or
.dockerignorestill reachingCOPY . .is accepted; every file reached the build onnext, and Docker reads the Dockerfile from the tar.Judgement call: a Dockerfile that is a symlink to a file the ignore file leaves out now failing the build is accepted; it needs both a linked Dockerfile and an ignore file that leaves out its target, too narrow a layout to hold the change back.
Judgement call: an ignore file that is a symlink out of the clone failing the build is accepted; in a fresh clone such a link cannot point at anything the repository holds.
Model: opus-5-5