moby / moby/buildkit

Build output always shows a mysterious .dockerignore

Open
#3,640 5 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

area/dockerfile area/ux
Dominant language
Go
Stars
10.3k
Forks
1.5k
Avg merge
1d 23h
Merged PRs (30d)
48

Description

This is one of those things that have probably always been there, but I just now noticed when posting a comment on https://github.com/moby/buildkit/issues/2511#issuecomment-1431412029.

When building a Dockerfile, which could be from stdin;

docker build -t foo -<<'EOF'
FROM alpine
RUN echo hello
EOF

Building the above shows:

[+] Building 1.9s (6/6) FINISHED
=> [internal] load build definition from Dockerfile                                                                    0.1s
=> => transferring dockerfile: 64B                                                                                     0.0s
=> [internal] load .dockerignore                                                                                       0.0s
=> => transferring context: 2B                                                                                         0.0s
=> [internal] load metadata for docker.io/library/alpine:latest                                                        0.9s
=> [1/2] FROM docker.io/library/alpine@sha256:69665d02cb32192e52e07644d76bc6f25abeb5410edc1c7a81a10ba3f0efb90a         0.5s
=> => resolve docker.io/library/alpine@sha256:69665d02cb32192e52e07644d76bc6f25abeb5410edc1c7a81a10ba3f0efb90a         0.0s
=> => sha256:63b65145d645c1250c391b2d16ebe53b3747c295ca8ba2fcb6b0cf064a4dc21c 3.37MB / 3.37MB                          0.2s
=> => sha256:69665d02cb32192e52e07644d76bc6f25abeb5410edc1c7a81a10ba3f0efb90a 1.64kB / 1.64kB                          0.0s
=> => sha256:e2e16842c9b54d985bf1ef9242a313f36b856181f188de21313820e177002501 528B / 528B                              0.0s
=> => sha256:b2aa39c304c27b96c1fef0c06bee651ac9241d49c4fe34381cab8453f9a89c7d 1.47kB / 1.47kB                          0.0s
=> => extracting sha256:63b65145d645c1250c391b2d16ebe53b3747c295ca8ba2fcb6b0cf064a4dc21c                               0.2s
=> [2/2] RUN echo hello                                                                                                0.4s
=> exporting to image                                                                                                  0.1s
=> => exporting layers                                                                                                 0.1s
=> => writing image sha256:136f47c90fc5b4fb4f1a440f668c971b936deeb060b6f833fe13e4fb3ee961c4                            0.0s
=> => naming to docker.io/library/foo

Notice that the output always shows that it's loading a .dockerignore, even though this build does not have a .dockerignore.

=> [internal] load .dockerignore                                                                                       0.0s
=> => transferring context: 2B                                                                                         0.0s

I'm guessing this is some implementation detail (perhaps an empty {} struct is sent accross the wire), but this is confusing, as a user could come to the conclusion that a .dockerignore is present "somewhere".

I wonder if we can either;

  • Suppress that output altogether (if theres no .dockerignore)
  • Suppress the 2B size
  • Or change the output to something informative (i.e., it checked if a .dockerignore is present, and found that there isn't)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the reported behavior with the Dockerfile-from-stdin command and compare the emitted .dockerignore progress lines. Trace the BuildKit output path that handles the absent ignore file; done means builds without a .dockerignore no longer display a misleading file load or size, with coverage for this case.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, go
Domain
build-system
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.