When a buid step is executed within a job running under a docker container (ie: via the Docker Custom Build Environment plugin), and the build step completes very quickly (ie: less than a second, say) console output produced by the build step does not get reported correctly in the Jenkins build log.

The most trivial reproducible case I've been able to find looks something like this:

1. create a new freestyle job
2. enable the "Build inside a docker container" option
   • I don't believe the particulars of how you setup your container are relevant, but we have a simple Dockerfile in the local workspace that we checkout from source control defining a fairly basic CentOS environment
3. create a single build step of type "Execute Shell"
4. in the command entry box enter the simple command: echo "hello world"
5. save the job and run it a few times

When examining the build logs you will see that sometimes the "hello world" string will be recorded in the log, while other times it will not. Based on some local ad-hoc tests it appears that sometimes the executor is able to grab the shell output before the container gets destroyed but other times it can not - perhaps dependent upon the load on the particular build agent at the time.

To help confirm my belief that this is a performance related issue I slightly modified my test case I just described by adding a "sleep 5" command to the end of the build step, forcing the build operation to block for at least a few seconds before the container gets destoryed. After doing so I am unable to reproduce this problem. The echo output gets correctly reported in the build log every time.

While this contrived example is quite trivial, in a more severe sense this defect worries me because I now wonder if there are cases when a more lengthy build step may have it's output truncated or otherwise corrupted in a production environment. I have not yet discovered such an example in our environment but I suspect it may be possible given my findings here. As such I would hope this bug would be considered somewhat high priority so a fix could be made sooner rather than later.