-
Type:
Bug
-
Status: Resolved
-
Resolution: Done
-
Affects Version/s: 2.1.4
-
Fix Version/s: 2.4.0
-
Component/s: None
-
Labels:None
-
Environment:
Artifactory Pro 2.6.6
Jenkins Core 1.480.3
Artifactory Plugin 2.1.4Linux
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.
- relates to
-
HAP-534 Artifactory release Promotion fails when 'Include dependencies' was checked once
- Resolved
-
RTFACT-6924 Moving artifacts that exist in multiple repositories can fail
- Done