构建推广是如何工作的

Artifactory中的Build Promotion是改变一个Build的状态的行为，通常是一个更成熟的状态。
成熟指包成熟度级别，如开发、分期和发布阶段。

Build Promotion允许您更改构建的状态，可选地将构建的构件及其依赖项移动或复制到目标存储库，并设置提升的构件的属性。

构建升级可以通过REST API，JFrog CLI，或者通过任何CI集成。
为所选对象触发“生成升级”操作Build-info身份在Artifactory。
注意build -info标识如何跟踪相关的构建工件是很重要的。每个build -info对象都是一个带有构建信息描述的JSON文件。

在build-info中。json中，产生的工件和使用的依赖项被引用为SHA1值。
构建是不可知的，他们的位置在Artifactory，他们的位置被设计为动态的促销。

Build标识通过它们的SHA1值以及Build .name和Build .name来知道它所生产的工件。数量的属性。

一旦构建提升被触发，Artifactory将首先搜索它应该提升的工件列表。它将根据build -info JSON中的SHA1值和build.name & build. JSON中的SHA1值进行搜索。数量的属性。
在检索它必须提升的工件列表之后，它将对该列表中的每个文件触发移动/复制操作。
然后，如果选中，新属性将附加到提升工件。
最后，更新构建的状态。

故障排除构建推广

为了排除构建升级问题，应用这些调试日志记录器应该很方便。

免责声明:修改日志级别会导致性能下降。应用于生产系统时请小心处理。

这个XML片段放在美元ARTIFACTORY_HOME / etc / logback.xml文件，不需要重启生效:
<文件> $ {artifactory.home} /日志/ build-promotion.log > < /文件
<编码器>
<模式> % $ {artifactory日期。contextId}[%线程][% 5 p] \ (% -20 c {3}: % L \) - m % n % > < /模式
< /编码器>
< rollingPolicy class = " ch.qos.logback.core.rolling.FixedWindowRollingPolicy " >
< FileNamePattern > $ {artifactory.home} /日志/ build-promotion. % i.log < / FileNamePattern >
13 < maxIndex > < / maxIndex >
< / rollingPolicy >
< triggeringPolicy class = " ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy " >
< < MaxFileSize > 25 mb / MaxFileSize >
< / triggeringPolicy >
< / appender >

<记录器name = " org.artifactory。建立“可加性= " false " >
<级别值= "跟踪" / >
< appender-ref ref = " build-promotion " / >
< / logger >

构建促进机制使用AQL以便搜索要推广的商品。我们可以将这个记录器添加到调试查询：<记录器name = " org.artifactory.storage.db。aql”相加性= " false " >
<级别值= "跟踪" / >
< appender-ref ref = " build-promotion " / >
< / logger >

解决问题复制/移动操作，应加上:<记录器name = " org.artifactory.repo.service。发“可加性= " false " >
<级别值= "跟踪" / >
< appender-ref ref = " build-promotion " / >
< / logger >

一个常见的误解

一个相对常见的场景是，构建通常发布到特定的目标位置:libs-snapshot-local: buildA /美元(版本号)/ /工件

作为一个用户，你会看到所有生成的工件都在目录中，所以你会假设在升级后相同的工件将存在于:填词,提升——:buildA /美元(版本号)/ /工件

然而，这可能并不总是发生。如上所述，构建推广搜索具有相同SHA1和build.name & build的工件。数量的属性。
因此，如果最初生成的工件被复制到Artifactory中的另一个位置，那么在提升期间，新位置可能首先返回搜索查询。当提升触发每个工件的复制/移动时，发现工件的路径将保留在目标存储库中。这意味着，如果一个带有属性的工件被复制到存储库的根，在提升之后，它可能存在于目标存储库的根，而不是预期的位置。