You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With buildkit enabled (the default) if an issue occurs during the build it is no longer trivial to diagnose by firing up a container based on the image of the previous build step.
For example if you have a Dockerfile with many RUN steps and one of them fails it is very useful to identify why they fail by spinning up a container based on the preceeding RUN steps image. before the buildkit change this image id was clearly visible.
I tried various options to --output however no value seemed to have any effect on the output.
I have tried with the latest version of Docker Desktop
I have tried disabling enabled experimental features
I have uploaded Diagnostics
Diagnostics ID:
Actual behavior
as shown below there is no mention of the intermediate container IDs
☸ docker-desktop:default master C:\workarea\source\github\jenkinsci\acceptance-test-harness\src\main\resources\org\jenkinsci\test\acceptance\docker\fixtures\SvnContainer>set DOCKER_BUILDKIT=0
☸ docker-desktop:default master C:\workarea\source\github\jenkinsci\acceptance-test-harness\src\main\resources\org\jenkinsci\test\acceptance\docker\fixtures\SvnContainer>docker build --no-cache -t svntest .
Sending build context to Docker daemon 18.94kB
Step 1/30 : FROM debian:buster
---> 4a7a1f401734
Step 2/30 : RUN export DEBIAN_FRONTEND=noninteractive && apt-get update && apt-get install -yq apache2 apache2-utils subversion libsvn-dev libapache2-mod-svn subversion-tools locales viewvc openssh-server supervisor && apt-get clean
---> Running in cb67825f6367
Get:1 http://security.debian.org/debian-security buster/updates InRelease [65.4 kB]
Get:2 http://security.debian.org/debian-security buster/updates/main amd64 Packages [291 kB]
Get:3 http://deb.debian.org/debian buster InRelease [121 kB]
---- snip ----
Removing intermediate container 714400203c47
---> 9a1602c77b93
Step 26/30 : RUN /usr/sbin/apache2 && svn checkout http://127.0.0.1/svn /svnRepo && svn add /svnRepo/* && svn commit -m 'init' /svnRepo/* && echo 'newRev' >> /svnRepo/testOne.txt && svn commit -m 'Rev with changes' /svnRepo/*
---> Running in 254d1eed1c7b
[Wed Jun 02 14:09:16.463507 2021] [so:warn] [pid 8] AH01574: module dav_module is already loaded, skipping
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
svn: E170013: Unable to connect to a repository at URL 'http://127.0.0.1/svn'
svn: E175002: Unexpected server error 500 'Internal Server Error' on '/svn'
The command '/bin/sh -c /usr/sbin/apache2 && svn checkout http://127.0.0.1/svn /svnRepo && svn add /svnRepo/* && svn commit -m 'init' /svnRepo/* && echo 'newRev' >> /svnRepo/testOne.txt && svn commit -m 'Rev with changes' /svnRepo/*' returned a non-zero code: 1
Expected behavior
as per the non buildkit option I would like to be able to clearly identify an image (or container) for the steps.
Information
Is it reproducible?
Yes
Is the problem new?
Yes
Did the problem appear with an update?
Yes (the introduction of buildkit)
A reproducible case if this is a bug, Dockerfiles with reproduction inside is best.
FROM debian:buster
RUN useradd user1
RUN useradd user2
RUN useradd user3
RUN useradd user1
RUN useradd user5
this will fail on a duplicate useradd - and this is a very contrived example where the cause of the error will be obvious from the logs and not need you to delve into the container, however consider something like apache where the setup error is caused by an incorrect configuration file much earlier in the setup and is not obvious in the build logs
Windows Version:
10 21H1
Docker Desktop Version:
3.3.3
WSL2 or Hyper-V backend?
WSL2
Are you running inside a virtualized Windows e.g. on a cloud server or a VM:
Nope
Steps to reproduce the behavior
using the docker file from above run docker build -t .
when the build fails try and identify the image from the last step that worked so you can fire up a container based on it for some interactive debugging.
The text was updated successfully, but these errors were encountered:
If you are looking a digest from the output it is image config that is used as an ID in docker.
edit: missed that you were not even referring to the image digest. These are LLB step digests for tracking (we've removed them to avoid confusion). Only build results are exported in BuildKit, when you set the output flag. For debugging, follow moby/buildkit#1472
With buildkit enabled (the default) if an issue occurs during the build it is no longer trivial to diagnose by firing up a container based on the image of the previous build step.
For example if you have a
Dockerfile
with manyRUN
steps and one of them fails it is very useful to identify why they fail by spinning up a container based on the preceedingRUN
steps image. before the buildkit change this image id was clearly visible.I tried various options to
--output
however no value seemed to have any effect on the output.Actual behavior
as shown below there is no mention of the intermediate container IDs
compared to
Expected behavior
as per the non buildkit option I would like to be able to clearly identify an image (or container) for the steps.
Information
Yes
Yes
Yes (the introduction of buildkit)
this will fail on a duplicate useradd - and this is a very contrived example where the cause of the error will be obvious from the logs and not need you to delve into the container, however consider something like apache where the setup error is caused by an incorrect configuration file much earlier in the setup and is not obvious in the build logs
10 21H1
3.3.3
WSL2
Nope
Steps to reproduce the behavior
run docker build -t .
The text was updated successfully, but these errors were encountered: