8000 Build ARG being overwritten in multistage build when using dind · Issue #42449 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Build ARG being overwritten in multistage build when using dind #42449

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cbuffett opened this issue May 31, 2021 · 3 comments
Closed

Build ARG being overwritten in multistage build when using dind #42449

cbuffett opened this issue May 31, 2021 · 3 comments

Comments

@cbuffett
Copy link

Description
When running a docker build command via a dind image, a build argument, PYTHON_VERSION is being overwritten in an intermediate stage. This does not happen when running the docker build command directly from the command line

Steps to reproduce the issue:

  1. Build the following dockerfile using the following command: docker build --target dev --pull --build-arg AIRFLOW_VERSION=2.0.1 --build-arg PYTHON_VERSION=3.7 --progress plain .
    Dockerfile.txt

  2. Observer that the pip3 constraint file is using the correct PYTHON_VERSION

  3. Run the same command inside docker:20.10.5-dind

  4. PYTHON_VERSION is overwritten to be 3.7.9

Describe the results you received:
PYTHON_VERSION is overwritten when building via dind, but is maintained when building from command-line

Describe the results you expected:
Build ARG passed in via command line is respected in all stages where ARG is declared

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client: Docker Engine - Community
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:14:11 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:18:31 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 33
 Server Version: 20.10.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 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: 269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.19.128-microsoft-standard
 Operating System: Alpine Linux v3.13 (containerized)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 24.97GiB
 Name: bd89fe158609
 ID: DL7R:RASG:WE3U:7HEH:PFPR:5PUO:X5SC:QWUN:U7UP:JWSI:XSVF:3MDM
 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
 Product License: Community Engine

WARNING: API is accessible on http://0.0.0.0:2375 without encryption.
         Access to the remote API is equivalent to root access on the host. Refer
         to the 'Docker daemon attack surface' section in the documentation for
         more information: https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Additional environment details (AWS, VirtualBox, physical, etc.):
OS: Ubuntu 20.04 WSL2

Log files from successful and failing builds
dind-build.txt
docker-build.txt

@thaJeztah
Copy link
Member

I see your non-DIND build uses BuildKit, but the DIND built uses the classic builder; are you able to reproduce the issue if you enable BuildKit for your DIND build? (set the DOCKER_BUILDKIT=1 environment variable?)

@cbuffett
Copy link
Author

Enabling BuildKit allowed the dind build to succeed.

@thaJeztah
Copy link
Member

Thanks for confirming that theory. I would recommend enabling Buildkit for your use-case. Looks like there's some (subtle) differences in how build-args are handled between the classic builder and BuildKit. With the plan to make BuildKit the default (#40379), I don't expect this to be something that will be fixed in the classic builder.

Because of the above, let me close this ticket, but feel free to continue the conversation 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants
0