配置完成构建触发器
当所选构建配置的构建完成时，finish build trigger 将启动当前构建配置的构建。
关键要点
当将 完成构建触发器 添加到配置A时，它会观察目标配置B，并在B完成另一次构建时产生一个新的A构建。
您可以选择是否只有在目标配置的构建成功时才触发构建。
完成构建触发器可以从指向相同目标配置的 快照依赖项 中受益。
除了跟踪目标配置的所有新构建外，您也可以仅在目标构建有新更改时触发新构建。 要做到这一点，您应使用 Schedule Trigger。
触发器设置
构建配置—— 选择一个要跟踪的构建配置。 请查看 触发器限制 部分，了解为何可能会显示快照依赖警告。
仅在构建成功后触发 — 此选项允许您在目标配置构建失败时，避免触发新的构建。
分支过滤器—— 一套以
+|-:<branch_name>格式的规则，允许您只观察特定分支的构建。 有关更多信息，请参见 分支过滤器。构建定制 — 提供与 运行自定义构建对话框 类似的选项。 有关更多信息，请参阅 触发构建自定义 部分。
完成构建触发器和快照
为了理解 完成构建触发器 和 快照依赖 之间的差异，我们来看以下例子。
一个示例项目有三个子构建配置：
这种配置确定当前日期并将其写入项目的 import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.csharpScript
object UpdateReleaseDate : BuildType({
name = "Update Release Date"
steps {
csharpScript {
id = "csharpScript"
content = """
var date = DateTime.Now.ToString("MM.dd.yyyy");
var serviceMessage = "##teamcity[setParameter name='product.release.date' value='" + date + "']";
Console.WriteLine(serviceMessage);
""".trimIndent()
tool = "%teamcity.tool.TeamCity.csi.DEFAULT%"
}
}
}) 这个配置增加了项目的 import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.script
object UpdateBuildVersion : BuildType({
name = "Update Build Version"
steps {
script {
id = "simpleRunner"
scriptContent = """
version=%build.version%
((version=version+1))
curl --location --request PUT 'http://<server_URL>/app/rest/projects/<project_name>/parameters/build.version' \
--header 'Accept: */*' \
--header 'Content-Type: text/plain' \
--header 'Authorization: Bearer your_token' \
--data ${'$'}version
""".trimIndent()
}
}
}) 这个配置重新发布了构件。 为了实现这一点，它首先需要实际的发布日期和构建编号，这些信息是从另外两个配置中获取的。
import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.script
import jetbrains.buildServer.configs.kotlin.triggers.finishBuildTrigger
object Delivery : BuildType({
name = "Update Packages"
steps {
script {
id = "simpleRunner"
scriptContent = """
echo "Delivery date is ${UpdateReleaseDate.depParamRefs["product.release.date"]}"
echo "Build version is %build.version%"
# TODO: Re-publish packages with updated version and date values
""".trimIndent()
}
}
triggers {
finishBuildTrigger {
buildType = "${UpdateBuildVersion.id}"
}
}
dependencies {
snapshot(UpdateReleaseDate) {
reuseBuilds = ReuseBuilds.NO
}
}
}) |
|---|
在此设置中，运行新的构建将产生以下结果：
如果触发了新的 "Update Release Date" 构建，其他配置将不会受到影响。 构建将计算一个新的参数值，但这个值在任何地方都不会被使用。
如果触发了 "Update Build Version" 配置，一旦这次构建完成，由于在这个配置中添加了 Finish build trigger，将会启动一个新的 "Update Packages" 配置构建。 然而，由于 "Update Packages" 也对 "Update Release Date"（禁用了 build reuse）有快照依赖，它也会请求当前日期。 因此，整个 "Update Build Version → Update Release Date → Update Packages" 管道将会运行。
如果触发了新的“Update Packages”构建，它将首先运行其依赖项“Update Release Date”构建。 发布版本将从项目参数中获取，而无需运行新的 "更新发布版本" 构建。
因此，交付构建始终确保日期正确，但除非“更新构建版本”配置产生新的构建，否则会重用现有的产品版本。 自动增加构建版本会自动触发交付过程。
触发器限制
当单独使用（没有在同一配置中使用 快照依赖关系）时，完成构建触发器 有以下限制：
新触发的构建可能不具有与已完成追踪构建相同的版本，即使两种配置具有相同的 VCS 设置。
如果具有完成构建触发器的构建配置具有目标构建配置的工件依赖性，那么就不能保证会使用被监视构建的工件。 这可能是因为在触发的构建位于构建队列时，跟踪配置的另一个构建可能已完成。
由完成构建触发器触发的构建将始终在默认分支中触发，即使已完成的构建使用了其他分支。
该算法并不保证每一个在被监视配置中完成的构建都会触发一个在具有完成构建触发器的配置中的相应构建。 在某些情况下，例如，如果两个被监控的构建相当同时地完成，可能只有一个相应的构建会被触发。 有关这个限制及其可能的解决方法的更多详情，敬请查看我们的问题追踪器中的 相关任务；如果这个限制以任何方式限制了您的构建管道，请在此问题下留言描述您的使用情况。
所有这些限制 不适用，如果具有完成构建触发器的构建配置对同一构建配置有快照依赖关系。 在这种情况下，触发器将在相同的修订版本上运行构建，并将构建附加到链上。 如果依赖项生成了一致的工件，它也将使用这些工件。 因此，如果不存在相应的快照依赖项，完成构建触发器设置对话框会显示警告，建议您同时使用这两个功能。
请注意，如果具有结束构建触发器的构建配置具有对所选构建配置的快照依赖关系，则该触发器将能够检测上一次监视的构建是否已经提升到当前构建配置（手动或由另一个触发器）。 在这种情况下，触发器不会运行新的构建。
触发构建自定义
触发器设置中的 Build Customization 标签允许配置由此触发器启动的构建的自定义参数。 与 Run Custom Build 对话框类似，它让您可以覆盖 构建参数 的值，并选择是否在构建前清理 检出目录。
在此选项卡中，您可以自定义当前构建配置中使用的任何参数的值。 或者，您可以添加一个新的参数，它将仅在由此触发器启动的构建中可用。 如果当前构建对其他构建有快照依赖，这样一个参数也可以用来覆盖依赖构建配置的某个属性：使用这个 reverse.dep.<dependencyBuildID>.<property> 语法。
请注意，如果您在触发器中重新定义了构建参数，然后在 参数 中删除了原始参数，那么它的重新定义值将被转换为触发器自己的纯文本参数。 在定制安全值时，这一点至关重要，因为只有与 "Password" 类型 一起存储时，它们才会被隐藏，如果转化为纯文本，它们将变得可读。
TeamCity 允许以多种方式解决类似的任务，在某些情况下，仍然优先创建不同的构建配置。 例如，如果在同一配置中有太多自定义运行，那么 TeamCity 预测每次构建的确切持续时间可能会更加困难。 如果您需要触发带有大量不同参数的构建，我们建议您创建一个 构建配置模板，并将其用作各种配置的蓝图，每种配置都有其自己的参数。