Start with the file Docker will actually use
Use the root .dockerignore when Docker builds with the file at the build-context root. If the selected Dockerfile has a sibling such aslint.Dockerfile.dockerignore, that file takes precedence. Test it alone because Docker does not merge it with the root file.
Useful probes sit around the boundary you are debugging: the directory named by a rule, a file below it, every exception, and the source of each COPY or ADDinstruction you care about. Enter them relative to the build-context root.
Docker patterns are ordered, not combined
Docker evaluates active lines from top to bottom. The last matching line decides whether a path is Included or Excluded, and a line beginning with ! creates an exception. Blank lines and the historical . pattern are inactive after preprocessing.
| Pattern | What it does |
|---|---|
foo/bar | Matches that context-relative path. Leading and trailing slashes are disregarded. |
*/temp* | Matches names beginning with temp inside an immediate child directory. |
**/*.go | Matches files ending in .go at any directory depth, including the context root. |
temp? | Matches a root name such as tempa, where ? stands for one character. |
!README.md | Creates an exception that includes the root README.md if an earlier rule excluded it. |
# note | Is a comment only when # is the first character in column 1. |
The deciding rule is the answer; the trace explains it
Every path starts Included. A normal matching line makes it Excluded, while a matching exception makes it Included again. The deciding rule is the last line that changed that state. Earlier matches stay in the trace so the result can be audited.
The built-in example uses docs followed by !docs/README.md.Parent means the first rule matched an ancestor while the submitted file was resolved. It is trace evidence, not the final verdict. The later Direct exception makesdocs/README.md Included by line 2.
When a result surprises you, check these four things
- Effective source: confirm whether the build uses the root file or a Dockerfile-specific file.
- Line order: a later matching rule can reverse every earlier match.
- Normalized input: compare the displayed normalized path and pattern diagnostics with what you pasted.
- Builder behavior: matcher verdicts for Docker control files do not describe all transfer or copy restrictions.
What this tester proves, and what it cannot
| Boundary | What it means |
|---|---|
| Path probes | Submitted paths are probes. They need not exist. |
| Matching | This is not a build or filesystem walk. It does not inspect symlinks, permissions, file sizes, or the source paths used by COPY and ADD. |
| Included | Included is not a safety guarantee. |
| Builder control files | Dockerfile, .dockerignore, and Dockerfile-specific ignore files have separate builder transfer behavior. |
| Effective source | A Dockerfile-specific ignore file takes precedence over the root file. The files are not merged. |
| Compatibility | This TypeScript compatibility port is pinned to and fixture-tested against Moby patternmatcher v0.6.1, not a claim about every current Docker build. |
| Local handling | Pattern testing uses the rules and paths already in this browser. There is no repository or file upload. |
Confirm the final context with Docker
For end-to-end proof, run a real build against the actual context and verify the relevantCOPY or ADD step. The official Docker documentationexplains file placement, pattern syntax, exceptions, and builder control files. If the machine is not ready yet, install Dockerfirst.