docker build --progress=none hides the stderr output of any failing command

[anordal]

Contributing guidelines and issue reporting guide

• I've read the contributing guidelines and wholeheartedly agree. I've also read the issue reporting guide.

Well-formed report checklist

• I have found a bug that the documentation does not mention anything about my problem
• I have found a bug that there are no open or closed issues that are related to my problem
• I have provided version/information about my environment and done my best to provide a reproducer

Description of bug

Bug description

There appears to be no way to hide normal progress output while preserving stderr from failing commands:

• docker build --quiet .
• docker build --progress=quiet .
• docker build --progress=none .

These all output the secondary failure, not the primary failure (see below):

Primary failure

ls: cannot access '/nonexisting': No such file or directory

Secondary failure:

ERROR: failed to build: failed to solve: process "/bin/sh -c ls /nonexisting" did not complete successfully: exit code: 2

Reproduction

1. To demonstrate, put a failing command in Dockerfile:

   RUN ls /nonexisting

2. Observe that without --quiet, we see progress, the primary failure and the secondary failure.

3. Observe that with --quiet (or any of the other options), we don't get to see the primary failure.

The objective is to disable progress output without hiding the primary error output.

Version information

Docker version 28.5.1-ce, build f8215cc26

[thaJeztah]

Could you elaborate a bit on your use-case? The progress is indeed hidden, but the final error should probably give the same information (including the line in the Dockerfile that produced the error);

echo -e 'FROM alpine\nRUN ls /nonexisting\n' | docker build --no-cache --progress=quiet -
Dockerfile:2
--------------------
   1 |     FROM alpine
   2 | >>> RUN ls /nonexisting
   3 |
   4 |
--------------------
ERROR: failed to build: failed to solve: process "/bin/sh -c ls /nonexisting" did not complete successfully: exit code: 1

After the build, it's also possible to get the full logs of the failing build can still be obtained through docker buildx history; you can filter on only builds that failed (status=error);

docker buildx history ls --filter status=error
BUILD ID                    NAME      STATUS    CREATED AT       DURATION
mn4mwldp1pp48wfc6kzte34xz             Error     34 seconds ago   2.2s       Open
ys694ixa3w3v45r27fo3ycb23             Error     7 days ago       1.0s       Open
gxibulvecug3z1gkxl457n2la             Error     7 days ago       4.4s       Open

And view those logs; default in plain output;

docker buildx history logs mn4mwldp1pp48wfc6kzte34xz
#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 70B 0.0s done
#1 DONE 0.0s

#2 [internal] load metadata for docker.io/library/alpine:latest
#2 DONE 1.4s

#3 [internal] load .dockerignore
#3 transferring context: 2B done
#3 DONE 0.0s

#4 [1/2] FROM docker.io/library/alpine:latest@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659
#4 resolve docker.io/library/alpine:latest@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659 0.0s done
#4 DONE 0.1s

#5 [2/2] RUN ls /nonexisting
#5 0.528 ls: /nonexisting: No such file or directory
#5 ERROR: process "/bin/sh -c ls /nonexisting" did not complete successfully: exit code: 1
------
 > [2/2] RUN ls /nonexisting:
0.528 ls: /nonexisting: No such file or directory
------

But you can specify the format, for example, ini rawjson if you want to programmatically parse the result;

docker buildx history logs --progress=rawjson mn4mwldp1pp48wfc6kzte34xz
{"vertexes":[{"digest":"sha256:2d073a4b051ccbd9354c5ed890d2ebaee6d872fefdbb3c8a46a9b78f62c68d9c","name":"[1/2] FROM docker.io/library/alpine:latest@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659"},{"digest":"sha256:446f2348e8b34b668775964de0075957294274c37080d2154c6511cfce2da923","name":"[internal] load build definition from Dockerfile"},{"digest":"sha256:fa2af498c463cb430607bdaaeca0c90ed88696164ea46ebacad5b906de1db429","name":"[internal] load .dockerignore"},{"digest":"sha256:08d01620727ab85bd589b0eab4d87708d2201db52f823d721954ce11be00ebbb","inputs":["sha256:2d073a4b051ccbd9354c5ed890d2ebaee6d872fefdbb3c8a46a9b78f62c68d9c"],"name":"[2/2] RUN ls /nonexisting"},{"digest":"sha256:446f2348e8b34b668775964de0075957294274c37080d2154c6511cfce2da923","name":"[internal] load build definition from Dockerfile","started":"2026-02-09T13:13:24.174876952Z","completed":"2026-02-09T13:13:24.176680121Z"},{"digest":"sha256:446f2348e8b34b668775964de0075957294274c37080d2154c6511cfce2da923","name":"[internal] load build definition from Dockerfile","started":"2026-02-09T13:13:24.179509433Z","completed":"2026-02-09T13:13:24.204103016Z"},{"digest":"sha256:038fafa2e280d24ac22549b7cef4c77fc469b484de8826b26b10bc92efa2f54d","name":"[internal] load metadata for docker.io/library/alpine:latest","started":"2026-02-09T13:13:24.24370972Z","completed":"2026-02-09T13:13:25.630779104Z"},{"digest":"sha256:fa2af498c463cb430607bdaaeca0c90ed88696164ea46ebacad5b906de1db429","name":"[internal] load .dockerignore","started":"2026-02-09T13:13:25.632673401Z","completed":"2026-02-09T13:13:25.632751641Z"},{"digest":"sha256:fa2af498c463cb430607bdaaeca0c90ed88696164ea46ebacad5b906de1db429","name":"[internal] load .dockerignore","started":"2026-02-09T13:13:25.633431979Z","completed":"2026-02-09T13:13:25.641364369Z"},{"digest":"sha256:2d073a4b051ccbd9354c5ed890d2ebaee6d872fefdbb3c8a46a9b78f62c68d9c","name":"[1/2] FROM docker.io/library/alpine:latest@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659","started":"2026-02-09T13:13:25.671035447Z","completed":"2026-02-09T13:13:25.705912524Z"},{"digest":"sha256:2d073a4b051ccbd9354c5ed890d2ebaee6d872fefdbb3c8a46a9b78f62c68d9c","name":"[1/2] FROM docker.io/library/alpine:latest@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659","started":"2026-02-09T13:13:25.706462407Z","completed":"2026-02-09T13:13:25.706631834Z"},{"digest":"sha256:2d073a4b051ccbd9354c5ed890d2ebaee6d872fefdbb3c8a46a9b78f62c68d9c","name":"[1/2] FROM docker.io/library/alpine:latest@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659","started":"2026-02-09T13:13:25.706804108Z","completed":"2026-02-09T13:13:25.725486406Z"},{"digest":"sha256:08d01620727ab85bd589b0eab4d87708d2201db52f823d721954ce11be00ebbb","inputs":["sha256:2d073a4b051ccbd9354c5ed890d2ebaee6d872fefdbb3c8a46a9b78f62c68d9c"],"name":"[2/2] RUN ls /nonexisting","started":"2026-02-09T13:13:25.729355004Z","completed":"2026-02-09T13:13:26.323001041Z","error":"process \"/bin/sh -c ls /nonexisting\" did not complete successfully: exit code: 1"}],"statuses":[{"id":"transferring dockerfile:","vertex":"sha256:446f2348e8b34b668775964de0075957294274c37080d2154c6511cfce2da923","name":"transferring","current":70,"timestamp":"2026-02-09T13:13:24.200020856Z","started":"2026-02-09T13:13:24.185954614Z","completed":"2026-02-09T13:13:24.200019923Z"},{"id":"transferring context:","vertex":"sha256:fa2af498c463cb430607bdaaeca0c90ed88696164ea46ebacad5b906de1db429","name":"transferring","current":2,"timestamp":"2026-02-09T13:13:25.637368778Z","started":"2026-02-09T13:13:25.635647636Z","completed":"2026-02-09T13:13:25.637368302Z"},{"id":"resolve docker.io/library/alpine:latest@sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659","vertex":"sha256:2d073a4b051ccbd9354c5ed890d2ebaee6d872fefdbb3c8a46a9b78f62c68d9c","current":0,"timestamp":"2026-02-09T13:13:25.705755741Z","started":"2026-02-09T13:13:25.680797734Z","completed":"2026-02-09T13:13:25.705737361Z"}],"logs":[{"vertex":"sha256:08d01620727ab85bd589b0eab4d87708d2201db52f823d721954ce11be00ebbb","stream":2,"data":"bHM6IC9ub25leGlzdGluZzogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQo=","timestamp":"2026-02-09T13:13:26.257348557Z"}]}

[anordal]

Use case:

• The failing command can fail in complex ways for external reasons.

  RUN uv sync

  This is why knowing which command failed and its exit status is really not saying much. You need its output.

• This is (also) running in CI.

  Whenever it fails for an external reason, you want to see what that was, without having to reproduce it locally.
  Logging into the right CI server and scrolling for the right failure is also making it more difficult than it needs to be.

• The command that runs docker build is used interactively (as a wrapper for an embedded toolchain). You don't want a screenful of ouput in the normal case when docker didn't rebuild because it was cached.