jenkins - 复制到另一个存储库时，无法通过内部版本号或最新版本解析 Artifactory

Question

在指定“分辨率详细信息” |“分辨率” |“分辨率” |“ Jenkins”时，我们很难使用Artifactory插件。解决的伪像（需要Artifactory Pro）（我将此值称为Artifactory-query-string）。
在这种情况下，我们对Artifactory的使用是提取现有模块（Artifactory中的单个ZIP文件），并且我们希望检索具有特定内部版本号或“ LATEST”内部构建抽象请求的特定模块。
当所需的模块/工件仅存在于一个存储库中时，我们可以获得所需的结果。但是，在某个模块的给定BUILD＃被“提升”后（通过Artifactory中的简单复制操作），我们便无法在其复制到的存储库中找到“提升”的工件。
工具/版本

詹金斯（2.7.2）
Artifactory Pro（4.11.2）
Jenkins的Artifactory插件（2.6.0）
Artifactory中具有“简单默认”布局的通用包装类型

背景
最近，我们引入了Jenkins Build＃作为工件的属性和工件文件名的一部分。
我们能够找到有关此“ Artifactory-query-string”的详细信息的唯一信息来源是通过位于输入区域旁边的问号图标提供的帮助信息。
我们对该帮助文本的解释表明：

如果要通过build_number（或“ LATEST”）进行检索，则还必须指定build_name值，换句话说，这两个值是相互依赖的

工作案例
以这种方式使用此功能时（仅在一个存储库中，称为DEV），一切都会按预期进行。只要我们还指定了build_name，我们就能使用build_number参数成功填写“ LATEST”或特定内部版本号的请求。
人工树

DEV（存储库）

somePath（路径）

myApplication-build-100.zip build_number：100 build_name：myJenkinsBuildJob
myApplication-build-101.zip构建编号：101构建名称：myJenkinsBuildJob
myApplication-build-102.zip build_number：102 build_name：myJenkinsBuildJob





Artifactory查询字符串
$DEV:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=>.\someFolder
此Artifactory-query-string将正确返回单个工件：myApplication-build-102.zip
失败案例
但是，在其中一个版本通过Artifactory中的简单COPY操作被“提升”到另一个存储库（例如QA）之后，我们无法弄清楚如何针对刚刚复制（“提升”）工件的QA存储库利用相同的功能。换句话说，我们无法在复制对象的存储库中“查找”复制/“提升”的工件。
人工树

DEV（存储库）

somePath（路径）

myApplication-build-100.zip build_number：100 build_name：myJenkinsBuildJob
myApplication-build-101.zip构建编号：101构建名称：myJenkinsBuildJob
myApplication-build-102.zip build_number：102 build_name：myJenkinsBuildJob




质量检查（存储库）

somePath（路径）

myApplication-build-102.zip build_number：102 build_name：myJenkinsBuildJob（从DEV存储库复制/“升级”）





Artifactory查询字符串
使用与之前相同的“ Artifactory-query-string”，但指定QA存储库而不是DEV
$QA:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=>.\someFolder
那么Jenkins的Artifactory插件将永远不会返回/找到任何东西：

Jenkins Artifactory Plugin version: 2.6.0
Beginning to resolve Build Info dependencies.
Finished resolving Build Info dependencies.
Beginning to resolve Build Info build dependencies.
Dependency on build [myJenkinsBuildJob], number [LATEST], pattern [QA:somePath/myApplication*.zip] - [0] results found.

有趣的是，如果我们删除DEV存储库中的原始工件，则针对QA的查询将正常工作。
观察到的行为似乎表明，给定的工件（基于文件名，内部版本号和内部名称）只能在一个存储库中定位/查询（解析），并且如果将工件复制到另一个存储库中，它将被“隐藏”。或对于此类查询被忽略。
这不是我们期望的行为。我们希望每个存储库都与其他存储库分开，并且对一个存储库的查询不应考虑任何其他存储库的任何内容-并且我们应该能够在复制的存储库中查找/查找/解析复制的模块至。
有人可以建议我在这里错过什么吗？我的期望错了吗？

Answer 1

这是具有构建信息的known issue，因为它仅通过校验和引用工件。如果您移动工件而不是复制工件，它将从正确的路径解析。