[HAP-396] Moving artifacts residing in multiple repositories can fail Created: 10/Apr/13  Updated: 11/Oct/15  Resolved: 23/Aug/15

Status: Resolved
Project: Jenkins Artifactory Plug-in
Component/s: None
Affects Version/s: 2.1.4
Fix Version/s: 2.4.0

Type: Bug Priority: Critical
Reporter: Patrick Renaud Assignee: Lior Hasson (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Environment:

Artifactory Pro 2.6.6
Jenkins Core 1.480.3
Artifactory Plugin 2.1.4

Linux


Issue Links:
Relationship
relates to HAP-534 Artifactory release Promotion fails w... Resolved
relates to RTFACT-6924 Moving artifacts that exist in multip... Resolved

 Description   

I encountered a disturbing situation that occurs only when promotion is executed via Jenkins. Copying or moving build artifacts straight from the Artifactory UI do not cause the same issue, which I describe below:

1-Create a maven build in Jenkins and stage it using the Artifactory Release Staging option. The resulting artifacts are deployed in the "dev" repository in which the Jenkins user has deploy and delete rights.

2-Next, use the Artifactory Release Promotion option in Jenkins to promote this build to the "qa" repository (copy the artifacts, do not move them). The Jenkins user has deploy rights to "qa" but not "delete". At this point the build artifacts exist in "dev" and in "qa" repositories.

3-Then, using the Artifactory Release Promotion option again in Jenkins, promote this build to the "release" repository, using the "move" option. We expect this to be denied, as the user does not have the permission to delete artifacts from "qa" (but he does from "dev"), but let's try anyhow. The dry-run fails to detect the missing user permission and attempts to run the command.

4-The result is that a subset of the build artifacts actually get copied to the "release" repository. VERY BAD!!!!

We end up with an inconsistent state for these build artifacts.



 Comments   
Comment by Lior Hasson (Inactive) [ 09/Aug/15 ]

Fixed under Artifactory project RTFACT-6924

Generated at Sun Nov 17 20:15:41 UTC 2019 using JIRA 7.6.16#76018-sha1:9ed376192612a49536ac834c64177a0fed6290f5.