Closed mandrije closed 5 years ago
+1 Having artifacts with the same content but different names is not that unlikely and should be supported. At least an option to ignore non-matching file names would be nice.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Closed due to inactivity
ISSUE TYPE
Jenkinsapi VERSION
0.3.6
Jenkins VERSION
2.121.3
SUMMARY
My Jenkins job generates multiple artifacts (XML-formatted test results in particular) and those don't defer much either across builds (job runs) or between each other. Therefore, it may easily happen that e.g. artifact_1 from build_1 has the same content (and therefore the same MD5 / fingerprint) as artifact_2 from build_2. To make the problem more obvious and easier to t-shoot, you may optionally turn on "Fingerprint all archived artifacts" option for the "Archive the artifacts" post-build action. In that case, Jenkins will you a table view of all the artifacts in each build and links between those that have the same content. In my example, Jenkins will show artifact_1 (from build_1) linked with artifact_2 (from build_2) as its "Original owner". When I'm using JenkinsAPI from Python and call Artifact.save() method for artifact_2 on build_2, I'm getting ArtifactBroken exception. Further debugging of Artifact.save() method shows that exception came from Artifact._verify_download() call, since Fingerprint.validate_for_build() returned False. And the reason for that was failing the (self._data["fileName"] != filename) check on line 80 since artifact_1 and artifact_2 obviously have different name. Good thing is that exception is thrown after the content is downloaded and save on the local file system, so I can catch and just ignore ArtifactBroken exception, but...
EXPECTED RESULTS
It would be best if no exception would be thrown at all in this case, as the file was downloaded correctly, its MD5 hash matches the one on Jenkins and the file is valid (i.e. it's not a broken artifact). It would also be acceptable if I'd get a different exception type that would be specific to this case, so I could decide what to do.
ACTUAL RESULTS
As explained in the description part, I'm getting a misleading ArtifactBroken just because the artifact content matches with some other artifact content from the past build.
USEFUL INFORMATION
All the details provided in the description, but please feel free to reach out for details.