Expected behavior
docker exec should always return a non-zero exit status when the command fails.
Actual behavior
This was not true at least once on an iMac running Docker Mac and Jenkins.
Information
Jenkins executes its job build script as this:
[Hyper-Server] $ /bin/sh -xe /var/folders/9z/s1_pyny92d93h7dlytdbjwbw0000gn/T/hudson603737622938412313.sh
…which then executes the build script in the repo as this:
./build-server.sh
…which itself starts with:
#!/bin/bash -ex
This is all to say that if any bash command fails, the build should break.
So far there’s been 160+ builds without any problems AFAIK: if there was problem during the build, it would break, otherwise it succeeds.
However, earlier today there was one build that succeeded even though it should have failed. By comparing the Jenkins build log (which captures everything) with the one of the previous build, I tracked it down to a single difference: in these 3 lines that build the image, docker exec failed without returning an error:
docker run --name production_ -v /Users/admin/Jenkins/Home/workspace/Hyper-Server/Server/docker/build:/build:ro -id {redacted}/hyper:base
docker exec production_ tar -xvf /build/hyper.tar
docker commit production_ {redacted}/hyper:production-{redacted}
And the reason it failed is that something went wrong with tar -xvf /build/hyper.tar: it’s like it abruptly stopped mid-course, without printing any error. So a bunch of files ended up missing in the production image.
Like I said, outside of this difference, everything else is the same in the build logs (the tar archive did contain the same files at time of creation).
Without restarting Docker or changing anything on the Mac, running the build again didn’t reproduce the problem.
Diagnostic from Docker:
Docker for Mac: version: mac-v1.12.0-beta16.2
OS X: version 10.11.5 (build: 15F34)
logs: /tmp/20160715-221246.tar.gz
failure: No error was detected
[OK] docker-cli
[OK] app
[OK] menubar
[OK] virtualization
[OK] system
[OK] osxfs
[OK] db
[OK] slirp
[OK] moby-console
[OK] logs
[OK] vmnetd
[OK] env
[OK] moby
[OK] driver.amd64-linux
Steps to reproduce the behavior
n/a