复制到另一个存储库时无法按内部版本号或最新解析工件
Cannot resolve Artifact by Build Number or LATEST when copied to another repository
我们在使用 Jenkins 的 Artifactory 插件 时遇到困难 解决方案详细信息 |已解决的工件(需要 Artifactory Pro)(我将此值称为 Artifactory-query-string)。
在这种情况下,我们对 Artifactory 的使用是拉取现有模块(Artifactory 中的单个 ZIP 文件),我们希望检索具有 特定构建号 的特定模块或 'LATEST' 构建的抽象请求。
当我们想要的模块/工件只存在于一个存储库中时,我们可以获得我们想要的结果。但是在模块的给定 BUILD # 已经 'promoted'(通过 Artifactory 中的简单复制操作)之后,我们无法在它被复制到的存储库中找到 'promoted' 工件。
工具/版本
- 詹金斯 (2.7.2)
- Artifactory 专业版 (4.11.2)
- Jenkins 的 Artifactory 插件 (2.6.0)
- Artifactory 中具有 'simple-default' 布局的通用包类型
背景
最近我们引入了 Jenkins Build # 作为工件的 属性 和工件文件名的一部分。
我们能够找到有关此 'Artifactory-query-string' 详细信息的唯一信息来源是通过输入区域旁边的问号图标提供的帮助信息。
我们对此帮助文本的解释表明:
- 如果要通过build_number(或'LATEST')检索,则build_name 值也必须指定,换句话说,这两个值是相互依赖的
工作案例
以这种方式使用此功能时(仅在一个存储库中 - 称为 DEV),一切都按预期工作。我们能够使用 build_number 参数成功填充 'LATEST' 或特定内部版本号的请求,只要我们还指定 build_name.
神器树
- 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-query-string
$DEV:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=>.\someFolder
这个 Artifactory-query-string 将正确地 return 单个工件:myApplication-build-102.zip
失败案例
然而,在这些构建之一通过 Artifactory 中的简单 COPY 操作 'promoted' 到另一个存储库(例如 QA 之后,我们无法弄清楚如何利用它针对刚刚复制工件的 QA 存储库 ('promoted') 的能力。换句话说,我们不能 'find' 复制的 / 'promoted' 工件在它被复制到的存储库中。
神器树
- 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 存储库复制/'promoted')
Artifactory-query-string
使用与以前相同的 'Artifactory-query-string',但指定 QA 存储库而不是 DEV
$QA:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=>.\someFolder
那么 Jenkins 的 Artifactory 插件永远不会 returns / 找到任何东西:
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 的查询将正常工作。
观察到的行为似乎表明给定的工件(基于文件名、构建#和构建名称)只能在一个存储库中定位/查询(解析),并且如果您将工件复制到另一个存储库,它对于此类查询,将 'hidden' 或忽略。
这不是我们预期的行为。我们希望每个存储库都与其他存储库分开,并且对一个存储库的查询不应考虑任何其他存储库的任何内容——并且我们应该能够在它被复制的存储库中定位/查找/解析复制的模块到.
任何人都可以建议我在这里缺少什么吗?我的期望有误吗?
这是一个带有构建信息的 known issue,因为它仅通过校验和引用工件。如果您移动工件而不是复制它们,它将从正确的路径解析。
自 Jenkins Artifactory 插件版本 2.9.0 起,file specs supports retrieving artifacts by build。
在这个新的实现中,您的场景有效。
您的下载规格应如下所示:
{
"files": [
{
"pattern": "${QA}/somePath/myApplication*.zip",
"target": "someFolder/",
"build" : "myJenkinsBuildJob/LATEST",
"flat": "false",
"recursive": "true"
}
]
}
我们在使用 Jenkins 的 Artifactory 插件 时遇到困难 解决方案详细信息 |已解决的工件(需要 Artifactory Pro)(我将此值称为 Artifactory-query-string)。
在这种情况下,我们对 Artifactory 的使用是拉取现有模块(Artifactory 中的单个 ZIP 文件),我们希望检索具有 特定构建号 的特定模块或 'LATEST' 构建的抽象请求。
当我们想要的模块/工件只存在于一个存储库中时,我们可以获得我们想要的结果。但是在模块的给定 BUILD # 已经 'promoted'(通过 Artifactory 中的简单复制操作)之后,我们无法在它被复制到的存储库中找到 'promoted' 工件。
工具/版本
- 詹金斯 (2.7.2)
- Artifactory 专业版 (4.11.2)
- Jenkins 的 Artifactory 插件 (2.6.0)
- Artifactory 中具有 'simple-default' 布局的通用包类型
背景
最近我们引入了 Jenkins Build # 作为工件的 属性 和工件文件名的一部分。
我们能够找到有关此 'Artifactory-query-string' 详细信息的唯一信息来源是通过输入区域旁边的问号图标提供的帮助信息。
我们对此帮助文本的解释表明:
- 如果要通过build_number(或'LATEST')检索,则build_name 值也必须指定,换句话说,这两个值是相互依赖的
工作案例
以这种方式使用此功能时(仅在一个存储库中 - 称为 DEV),一切都按预期工作。我们能够使用 build_number 参数成功填充 'LATEST' 或特定内部版本号的请求,只要我们还指定 build_name.
神器树
- 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
- somePath(路径)
Artifactory-query-string
$DEV:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=>.\someFolder
这个 Artifactory-query-string 将正确地 return 单个工件:myApplication-build-102.zip
失败案例
然而,在这些构建之一通过 Artifactory 中的简单 COPY 操作 'promoted' 到另一个存储库(例如 QA 之后,我们无法弄清楚如何利用它针对刚刚复制工件的 QA 存储库 ('promoted') 的能力。换句话说,我们不能 'find' 复制的 / 'promoted' 工件在它被复制到的存储库中。
神器树
- 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
- somePath(路径)
- QA(存储库)
- somePath(路径)
- myApplication-build-102.zip build_number: 102 build_name: myJenkinsBuildJob(从 DEV 存储库复制/'promoted')
- somePath(路径)
Artifactory-query-string
使用与以前相同的 'Artifactory-query-string',但指定 QA 存储库而不是 DEV
$QA:somePath/myApplication*.zip@myJenkinsBuildJob#$LATEST=>.\someFolder
那么 Jenkins 的 Artifactory 插件永远不会 returns / 找到任何东西:
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 的查询将正常工作。
观察到的行为似乎表明给定的工件(基于文件名、构建#和构建名称)只能在一个存储库中定位/查询(解析),并且如果您将工件复制到另一个存储库,它对于此类查询,将 'hidden' 或忽略。
这不是我们预期的行为。我们希望每个存储库都与其他存储库分开,并且对一个存储库的查询不应考虑任何其他存储库的任何内容——并且我们应该能够在它被复制的存储库中定位/查找/解析复制的模块到.
任何人都可以建议我在这里缺少什么吗?我的期望有误吗?
这是一个带有构建信息的 known issue,因为它仅通过校验和引用工件。如果您移动工件而不是复制它们,它将从正确的路径解析。
自 Jenkins Artifactory 插件版本 2.9.0 起,file specs supports retrieving artifacts by build。
在这个新的实现中,您的场景有效。
您的下载规格应如下所示:
{
"files": [
{
"pattern": "${QA}/somePath/myApplication*.zip",
"target": "someFolder/",
"build" : "myJenkinsBuildJob/LATEST",
"flat": "false",
"recursive": "true"
}
]
}