Disable the new fancy TUI in favor of old simple build/run output

[and3rson]

Is there any way to replace this sort of logging (2.0+):

...with the old one (1.x)?

I found docker-compose build --progress plain which eliminates the fancy new progress output, but there are some other issues:

• This works for build only, I could not find anything similar for up
• This still produces logs in some weird new format:

...
#19 [chrysalis/frontend-dev 4/6] RUN npm install
#19 sha256:4452d990ec017d2c1ca515694e30c74e9318096ec457a98eedc54068c3ea8d53
#19 CACHED

#16 [chrysalis/frontend-dev 2/6] WORKDIR /home/frontend
#16 sha256:09d1943a3a59f942dde187c4b68705a078a77272ed71282b4565396b4ec00ca4
#16 CACHED

#18 [chrysalis/frontend-dev 3/6] COPY package.json package-lock.json ./
#18 sha256:dcc7f9017c1443e55727129375c70d2c8785ed9e1e3b4759811fc84b18a6f5a8
#18 CACHED
...

Output of docker compose version:

Docker Compose version 2.0.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., 2.0.1)

Server:
 Containers: 10
  Running: 0
  Paused: 0
  Stopped: 10
 Images: 1361
 Server Version: 20.10.8
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 72cec4be58a9eb6b2910f5d10f1c01ca47d231c0.m
 runc version: v1.0.2-0-g52b36a2d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.14.8-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.44GiB
 Name: vivo
 ID: Y6JF:RTEL:F4XP:DWFL:YBWQ:5VMT:BN54:P326:OJSQ:FOKY:CH7H:NO6H
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

EDIT: My temporary solution was to downgrade to 1.29.2. I'm afraid this won't last long.

[nocive]

@and3rson you can fallback to plain text output with BUILDKIT_PROGRESS=plain which supports all the values that the --progress flag does, ie: auto|plain|tty. However, that's still not the "old simple build/run output" that you crave for.

[Shikachuu]

The "old output" was docker's default build system, the "new" is buildkit's output.
Basically in v2 docker compose build use buildkit explicitly, so your only way to get a simpler output is in @nocive comment.

[thaJeztah]

This still produces logs in some weird new format:

@and3rson yes, the format is different with BuildKit; BuildKit builds can run build-steps in parallel, so the output won't be "sequential" as in the old builder. The numbers before each step (e.g. #18) in the "pain text output" allows the output to be parsed programmatically to correlate build-steps, but it will be slightly less easy to read (due to the parallel nature of build-steps). That said, there may be some output that can be omitted to make it slightly more readable.

For your use-case, is there a specific reason why the new output is problematic for you? If so, could you describe your use-case? Perhaps there's enhancements to be made to address.

[clrxbl]

This still produces logs in some weird new format:

@and3rson yes, the format is different with BuildKit; BuildKit builds can run build-steps in parallel, so the output won't be "sequential" as in the old builder. The numbers before each step (e.g. #18) in the "pain text output" allows the output to be parsed programmatically to correlate build-steps, but it will be slightly less easy to read (due to the parallel nature of build-steps). That said, there may be some output that can be omitted to make it slightly more readable.

For your use-case, is there a specific reason why the new output is problematic for you? If so, could you describe your use-case? Perhaps there's enhancements to be made to address.

I'm not the person who created this issue but I have one complaint about the new output as well.
First of all, I love BuildKit's output in docker build. But, compose's implementation makes me question how this made it through an official 2.0 release.

xEoPf4fzPn_1.mp4

This can be reproduced in both Windows' command prompt, Windows Terminal and probably others. It literally spams thousands of lines to the terminal ruining the ability to scroll back. Sorry if I'm hijacking the issue but it seemed fairly fitting as I have to resort to rolling back to a 1.x release.

[thaJeztah]

It literally spams thousands of lines to the terminal ruining the ability to scroll back

Looks like your compose file is pulling a lot of images (61), each with many layers, yes, I can see that may not scale well if it's refreshing all of that. Perhaps it should collapse some of that if the number of image is > X images.
I assume the "scrolling back" problem occurs during the build/pull, but work afterwards, correct?

Could you open a new ticket for that?

[sjoqvist]

@thaJeztah

For your use-case, is there a specific reason why the new output is problematic for you? If so, could you describe your use-case? Perhaps there's enhancements to be made to address.

I'm not the one who created the issue either, but what I miss is the hash for the intermediate images, so that I can start containers based on steps in multi-stage builds that don't get their own tags.

With plain output the new format does output some kind of SHA256 hash, but its meaning is unclear to me and I haven't been able to use it to launch a container.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.