构建推广是如何工作的

Artifactory中的构建提升是将构建状态更改为更成熟状态的操作。
成熟指包的成熟度级别，如开发、分级和发布阶段。

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

Build Promotion可以通过以下方式触发REST API，JFrog CLI，或通过任何CI集成。
生成提升操作将为选定的Build-info身份在Artifactory。
注意build -info标识如何跟踪相关的构建工件是很重要的。每个build -info对象都是一个JSON文件，其中包含对构建信息的描述。

在build-info中。生成的工件和使用的依赖项被引用为SHA1值。
建筑与他们在Artifactory中的位置无关，他们的位置被设计为动态的促销。

构建标识通过其SHA1值以及Build .name & Build来了解其生成的工件。数量的属性。

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

解决构建升级问题

为了解决构建升级问题，应用这些调试日志程序应该很方便。

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

这个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 >

的问题进行故障排除复制/移动操作在Build Promotion中，应该添加以下内容:<记录器name = " org.artifactory.repo.service。发“可加性= " false " >
<级别值= "跟踪" / >
< appender-ref ref = " build-promotion " / >
< / logger >

常见的误解

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

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

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