Downloading a ZIP archive of the workspace from a project that was built on a slave appears to be broken since Hudson 1.378 (found by bisection between 1.365 and 1.406-SNAPSHOT). It worked and still works when the project was built on the master, so no remoting takes place.
How to reproduce:
- Set up a free-style project that just creates a few files in the workspace, such as:
- Restrict this project to run on a slave (connected via SSH in my case).
- Run this project.
- Using the "(all files in zip)" link, download the workspace and verify the downloaded Zip archive. With 1.377 and before, you can run the download and verification step in a loop from the command line for 100 times in a row without error. Since 1.378, it will usually fail at the second attempt and will, on first glance at the hexdump, look like a correct but truncated Zip archive. The script that I used for testing is this:
- Run the job on the Jenkins master. (This isn't an option in our setup.)
Possibly related issues:
The changelog of 1.378 mentions
JENKINS-5977 "Improving the master/slave communication to avoid pipe clogging problem." and I suspect that this change introduced the problem. A later changelog entry for 1.397 mentions that it fixed "a master/slave communication problem since 1.378" ( JENKINS-7745). However, using the steps described above I can still reproduce at least this issue, even in the current version 1.404 and the latest snapshot.
As suggested in comments of other issues touching on the field of master/slave communication, it would seem reasonable to assume that this issue could be caused by a missing flush operation on an output stream, or something to that effect. Another possibility, however likely, might be the suspected thread concurrency problem noted in remoting/src/main/java/hudson/remoting/PipeWindow.java, where it also mentions the issues
JENKINS-7745 or JENKINS-7581.