-
Bug
-
Resolution: Unresolved
-
Minor
-
compress-artifacts-plugin 1.10
Jenkins 2.73.2
Windows Server 2012 R2
I put two archiveArtifacts steps in a declarative Jenkinsfile but only the files archived by the first step show up in the Jenkins UI.
dir('bin/Release') { archiveArtifacts artifacts: 'data/*.xml', fingerprint: true, onlyIfSuccessful: true archiveArtifacts artifacts: '**/*', excludes: '**/*.xml', fingerprint: true, onlyIfSuccessful: true }
The build directory in the Jenkins master then contains both "archive.zip" with files from the first step, and "archive.zip.writing.zip" with files from the second step. I think the tempArchive.renameTo(archive); call in ZipStorage failed. There is a comment "TODO support updating entries", so this is apparently a known problem.
However, if this kind of thing is not supported, then I think the build should at least have failed with an explanation in Console Output. I got no warnings there, and the build succeeded:
[Pipeline] dir
Running in CENSORED\bin\Release
[Pipeline] {
[Pipeline] archiveArtifacts
Archiving artifacts
Recording fingerprints
[Pipeline] archiveArtifacts
Archiving artifacts
Recording fingerprints
[Pipeline] }
[Pipeline] // dir
[Pipeline] }
[JENKINS-47748] Second archiveArtifacts step fails silently with compress-artifacts-plugin
Kalle Niemitalo
created issue -
Kalle Niemitalo
added a comment - The error-handling flaw seems distinct from JENKINS-45200, in which the job ultimately failed. Here, the job succeeded but some of the artifacts were missing.
Kalle Niemitalo
added a comment - The error-handling flaw seems distinct from JENKINS-45200 , in which the job ultimately failed. Here, the job succeeded but some of the artifacts were missing. Kalle Niemitalo
added a comment - The tempArchive.renameTo(archive) call goes to File.renameTo(File), which returns false if it fails, and compress-artifacts-plugin ignores this return value. So, that's why the run succeeded despite the error.
I didn't find any other places where the plugin ignores return values from File.
Kalle Niemitalo
added a comment - The tempArchive.renameTo(archive) call goes to File.renameTo(File) , which returns false if it fails, and compress-artifacts-plugin ignores this return value. So, that's why the run succeeded despite the error.
I didn't find any other places where the plugin ignores return values from File. 
Lubo Varga
added a comment - I am using scripted pipeline, where there are multiple parallel build steps (owasp dependency check, mvn test, code coverage) and they could run on different nodes/dockers, so I need to call archiveArtifacts multiple times.
Is there any methodical workaround for situations like these?
Lubo Varga
added a comment - I am using scripted pipeline, where there are multiple parallel build steps (owasp dependency check, mvn test, code coverage) and they could run on different nodes/dockers, so I need to call archiveArtifacts multiple times.
Is there any methodical workaround for situations like these? This is just not implemented in compress-artifacts plugin. It should not be that difficult as underlying truezip library appears to support that.
Help wanted!
Kalle Niemitalo
added a comment - luvarqpp, a workaround might be to stash the files from each node and unstash all of them to the same node, then archive them from there using only one archiveArtifacts step.
Kalle Niemitalo
added a comment - luvarqpp , a workaround might be to stash the files from each node and unstash all of them to the same node, then archive them from there using only one archiveArtifacts step. | Assignee | Original: Oliver Gondža [ olivergondza ] |
Kalle Niemitalo
added a comment - I finally tried the workaround. It works, but it is quite inconvenient with matrix because you need to give each stash a unique name and later unstash them with the same names. matrix in Declarative Pipeline doesn't support taking the axis values from a variable, so you cannot define the list of values just once and then use that both in matrix and in a loop that runs unstash.
Kalle Niemitalo
added a comment - I finally tried the workaround. It works, but it is quite inconvenient with matrix because you need to give each stash a unique name and later unstash them with the same names. matrix in Declarative Pipeline doesn't support taking the axis values from a variable, so you cannot define the list of values just once and then use that both in matrix and in a loop that runs unstash . Kalle Niemitalo
added a comment - Thinking about how to fix this. There might be a problem if multiple agents in a parallel build run archiveArtifacts steps at the same time, and multiple threads in the Jenkins controller then attempt to update the same zip file. I suppose I should look at how the similar problem has been solved in the fingerprint storage.
Kalle Niemitalo
added a comment - Thinking about how to fix this. There might be a problem if multiple agents in a parallel build run archiveArtifacts steps at the same time, and multiple threads in the Jenkins controller then attempt to update the same zip file. I suppose I should look at how the similar problem has been solved in the fingerprint storage.
Correct, with truezip this should be possible to implement.