labels assigned in inconsistent/random order via docker build --label #29619
Description
Description
It appears the ordering of multiple --label options passed to docker build is strangely random and not preserved -- so if we run the same docker build command multiple times, we can get different images.
This is mucking up the build cache and creating superfluous layers/images -- which is slowing builds when multiple labels are passed via the cli.
Steps to reproduce the issue:
The more--label options passed, the easier it is to repeat. I'll demonstrate with 5 labels, running the command 9 times, using the same Dockerfile.
- Create simple Dockerfile
echo "FROM debian:jessie" > Dockerfile- build an image, passing labels via the cli
docker build -t labeltest \
--label=org.a="cli-a" \
--label=org.b="cli-b" \
--label=org.c="cli-c" \
--label=org.d="cli-d" \
--label=org.e="cli-e" \
.- run the same build command over and over
build/image(){
docker build -t labeltest \
--label=org.a="cli-a" \
--label=org.b="cli-b" \
--label=org.c="cli-c" \
--label=org.d="cli-d" \
--label=org.e="cli-e" \
.
}
for i in {1..9}; do
echo "## build attempt $i , $(build/image | grep LABEL)"
doneDescribe the results you received:
## build attempt 1 , Step 2 : LABEL "org.c" "cli-c" "org.d" "cli-d" "org.e" "cli-e" "org.a" "cli-a" "org.b" "cli-b"
## build attempt 2 , Step 2 : LABEL "org.e" "cli-e" "org.a" "cli-a" "org.b" "cli-b" "org.c" "cli-c" "org.d" "cli-d"
## build attempt 3 , Step 2 : LABEL "org.c" "cli-c" "org.d" "cli-d" "org.e" "cli-e" "org.a" "cli-a" "org.b" "cli-b"
## build attempt 4 , Step 2 : LABEL "org.d" "cli-d" "org.e" "cli-e" "org.a" "cli-a" "org.b" "cli-b" "org.c" "cli-c"
## build attempt 5 , Step 2 : LABEL "org.d" "cli-d" "org.e" "cli-e" "org.a" "cli-a" "org.b" "cli-b" "org.c" "cli-c"
## build attempt 6 , Step 2 : LABEL "org.a" "cli-a" "org.b" "cli-b" "org.c" "cli-c" "org.d" "cli-d" "org.e" "cli-e"
## build attempt 7 , Step 2 : LABEL "org.a" "cli-a" "org.b" "cli-b" "org.c" "cli-c" "org.d" "cli-d" "org.e" "cli-e"
## build attempt 8 , Step 2 : LABEL "org.b" "cli-b" "org.c" "cli-c" "org.d" "cli-d" "org.e" "cli-e" "org.a" "cli-a"
## build attempt 9 , Step 2 : LABEL "org.b" "cli-b" "org.c" "cli-c" "org.d" "cli-d" "org.e" "cli-e" "org.a" "cli-a"
You'll see the LABEL step is inconsistent, and it creates a new layer because of the changed ordering.
Describe the results you expected:
The LABEL to remain consistent, so we don't randomly create new layers/images.
Output of docker version:
$ docker version
Client:
Version: 1.12.3
API version: 1.24
Go version: go1.7.3
Git commit: 6b644ec
Built: Thu Oct 27 19:42:59 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.1
API version: 1.24
Go version: go1.7
Git commit: 23cf638
Built: Fri Aug 19 02:03:02 2016
OS/Arch: linux/amd64
Output of docker info:
Containers: 91
Running: 0
Paused: 0
Stopped: 91
Images: 1049
Server Version: 1.12.1
Storage Driver: overlay
Backing Filesystem: f2fs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.7.2-1-ARCH
Operating System: Arch Linux
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.747 GiB
Name: hartford
ID: KVIO:FKIX:BTN6:RAMN:W5TV:3IB3:2NCV:NYDB:L37L:OHZ5:3IOH:O444
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: briceburg
Registry: https://index.docker.io/v1/
Insecure Registries:
127.0.0.0/8
Additional environment details (AWS, VirtualBox, physical, etc.):
bare metal arch linux