复制到另一个存储库时,无法通过内部版本号或LATEST解析工件

Question

在指定分辨率详细信息时,我们在使用Jenkins的Artifactory插件时遇到了困难 已解决的工件(需要Artifactory Pro)(我将此值称为Artifactory-query-string).

在这种情况下,我们对Artifactory的使用是拉取现有模块(Artifactory中的单个ZIP文件),我们希望检索具有特定内部版本号或" 最新 "构建的抽象请求的特定模块.

当我们想要的模块/工件只存在于一个存储库中时,我们可以得到我们想要的结果.但是,在一个模块的给定BUILD#被"提升"(通过Artifactory中的简单复制操作)之后,我们无法在它被复制到的存储库中找到"提升"工件.

工具/版本

• 詹金斯(2.7.2)
• Artifactory Pro(4.11.2)
• Jenkins的Artifactory插件(2.6.0)
• Generic Package在Artifactory中使用"simple-default"布局

背景

最近我们引入了Jenkins Build#作为工件的属性和工件文件名的一部分.

我们能够通过有关此"Artifactory-query-string"的详细信息找到的唯一信息来源是通过输入区旁边的问号图标提供的帮助信息.

我们对此帮助文本的解释表明:

• 如果想要通过build_number(或'LATEST')检索,那么也必须指定build_name值,换句话说,这两个值是相互依赖的

工作案例

以这种方式使用此功能时(仅在一个存储库中称为DEV),一切都按预期工作.只要我们还指定了build_name,我们就可以使用build_number参数成功填写'LATEST'或特定Build Number 的请求.

Artifactory树

• DEV(存储库)
  • somePath(路径)
    • myApplication-build-100.zip build_number:100 build_name:myJenkinsBuildJob
    • myApplication-build-101.zip build_number:101 build_name: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存储库进行复制("提升").换句话说,我们无法在复制到它的存储库中"找到"复制的/"提升的"工件.

Artifactory树

• DEV(存储库)
  • somePath(路径)
    • myApplication-build-100.zip build_number:100 build_name:myJenkinsBuildJob
    • myApplication-build-101.zip build_number:101 build_name:myJenkinsBuildJob
    • myApplication-build-102.zip build_number:102 build_name:myJenkinsBuildJob
• QA(存储库)
  • somePath(路径)
    • myApplication-build-102.zip build_number:102 build_name:myJenkinsBuildJob(从DEV存储库复制/' promote ')

Artifactory-query-string
使用与以前相同的'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

这是构建信息的已知问题,因为它仅通过校验和引用工件.如果移动工件而不是复制工件,它将从正确的路径解析.