-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
RedHat Enterprise Linux 7
Jenkins 2.263.2
Jenkins 2.263.3
Since Jenkins 2.263.2 the format of the artifact Zip archive changed in a way that breaks the Azure DevOps plugin we are using to download Jenkins job artifacts after a job has finished. The archives downloaded from Jenkins 2.263.1 and 2.263.2+ contain exactly the same files (as expected), but differ when using binary comparison. This was tested by downloading artifacts from the same build in version 2.263.1 and 2.263.2/2.263.3. I attached one archive downloaded from 2.263.1 and one archive downloaded from 2.263.3.
Since there is no easy workaround we had to roll back to 2.263.1.
- relates to
-
JENKINS-53874 ZipArchiver should set the type bits when setting the Unix mode
-
- Open
-
It seems that you're relying on a binary comparison of the zip file itself. Isn't that much more brittle than is required?
The purpose of the zip file is to provide all the files and directories from the source location in the workspace. Relying on the precise ordering of files in the zip archive or precise compression levels or other internal details of the zip file format seems more precise than the zip archive of files in the workspace was ever intended to be. Since the changes in Jenkins 2.263.2 resolved one or more security issues with that change, I doubt that the maintainers will be willing to work to provide that level of compatibility.