本文档的内容是由机器翻译的。请通过反馈微件提交您的反馈。
 

配置完成构建触发器

最后修改日期： 2025年 3月 21日

当所选构建配置的构建完成时， finish build trigger 将启动当前构建配置的构建。

关键要点

  • 当 完成构建触发器 被添加到配置 A 时，它会监视目标配置 B，并在 B 完成另一个构建时生成一个新的 A 构建。

  • 您可以选择是否只有在目标配置的构建成功时才触发构建。

  • 完成构建触发器可以从指向相同目标配置的 快照依赖项 中受益。

  • 除了跟踪目标配置的所有新构建外，您也可以仅在目标构建有新更改时触发新构建。 要做到这一点，您应使用 Schedule Trigger。

触发器设置

完成构建触发器设置

  • Build configuration（构建配置） — 选择一个构建配置进行跟踪。 请查看 触发器限制 部分，了解为何可能会显示快照依赖警告。

  • 仅在成功构建后触发 — 允许您在目标配置的构建失败时避免触发新的构建。

  • 分支过滤器 — 一组以 +|-:<branch_name> 格式编写的规则，允许您仅监视特定分支的构建。 有关更多信息，请参见 分支过滤器。

  • 构建自定义 — 提供类似于 运行自定义构建对话框 的选项。 有关更多信息，请参阅 触发构建自定义 部分。

完成构建触发器和快照

为了理解 完成构建触发器 和 快照依赖 之间的区别，让我们来看以下示例。

一个示例项目有三个子构建配置：

链图

这种配置确定当前日期并将其写入项目的 产品发布日期 参数。 请注意，由于新参数是用 setParameter 服务信息 编写的，新值只在此构建的范围内生效。

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%"
        }
    }
})

在此设置中，运行新的构建将产生以下结果：

  • 如果触发了新的 "Update Release Date" 构建，其他配置将不会受到影响。 构建将计算一个新的参数值，但这个值在任何地方都不会被使用。

    触发更新发布日期

  • 如果触发了 "Update Build Version" 配置，一旦此构建完成，将会因为添加到此配置的 完成构建触发器 生成一个新的 "Update Packages" 配置构建。 然而，由于 "Update Packages" 也对 "Update Release Date"（禁用了 build reuse ）有快照依赖，它也会请求当前日期。 因此，整个 "Update Build Version → Update Release Date → Update Packages" 管道将会运行。

    触发更新构建版本

  • 如果触发了新的“Update Packages”构建，它将首先运行其依赖项“Update Release Date”构建。 发布版本将从项目参数中获取，而无需运行新的 "更新发布版本" 构建。

    触发更新程序包

因此，交付构建始终确保日期正确，但除非“更新构建版本”配置产生新的构建，否则会重用现有的产品版本。 自动增加构建版本会自动触发交付过程。

触发器限制

单独使用时（没有对同一配置的 快照依赖）， 完成构建触发器 存在以下限制：

  • 新触发的构建可能不具有与已完成追踪构建相同的版本，即使两种配置具有相同的 VCS 设置。

  • 如果具有完成构建触发器的构建配置具有目标构建配置的工件依赖性，那么就不能保证会使用被监视构建的工件。 这可能是因为在触发的构建位于构建队列时，跟踪配置的另一个构建可能已完成。

  • 由完成构建触发器触发的构建将始终在默认分支中触发，即使已完成的构建使用了其他分支。

  • 该算法并不保证每一个在被监视配置中完成的构建都会触发一个在具有完成构建触发器的配置中的相应构建。 在某些情况下，例如，如果两个被监控的构建相当同时地完成，可能只有一个相应的构建会被触发。 有关这个限制及其可能的解决方法的更多详情，敬请查看我们的问题追踪器中的 相关任务 ；如果这个限制以任何方式限制了您的构建管道，请在此问题下留言描述您的使用情况。

如果具有完成构建触发器的构建配置对同一构建配置具有快照依赖，则所有这些限制 不适用。 在这种情况下，触发器将在相同的修订版本上运行构建，并将构建附加到链上。 如果依赖项生成了一致的工件，它也将使用这些工件。 因此，如果不存在相应的快照依赖项，完成构建触发器设置对话框会显示警告，建议您同时使用这两个功能。

请注意，如果具有完成构建触发器 具有 的构建配置对所选构建配置具有快照依赖，则触发器将能够检测最后监视的构建是否已被手动或通过另一个触发器提升到当前构建配置。 在这种情况下，触发器不会运行新的构建。

触发构建自定义

触发器设置的 构建自定义 选项卡允许配置由此触发器启动的构建的自定义参数。 与 Run Custom Build 对话框类似，它让您可以覆盖 构建参数 的值，并选择是否在构建前清理 检出目录。

在此选项卡中，您可以自定义当前 构建配置中使用的任何 参数的值。 或者，您可以添加一个新的参数，它将仅在由此触发器启动的构建中可用。 如果当前构建对其他构建有 快照依赖 ，这样一个参数也可以用来 覆盖依赖构建配置的某个属性 ：使用这个 reverse.dep.<dependencyBuildID>.<property> 语法。

tip

如果您将此功能与 build step execution conditions 结合使用，效果会更好。 您只需向步骤添加一个基于参数的条件，然后配置两个触发器：一个将运行包含此步骤的构建（条件满足时），另一个则会运行不包含此步骤的构建。 一种常见的用例是在常规构建中运行有限的测试，但在夜间构建中，当服务器负载最低时，运行完整的测试集。

请注意，如果您在触发器中重新定义了构建参数，然后在 参数 中删除了原始参数，其重新定义的值将被转换为触发器自己的纯文本参数。 在定制安全值时，这一点至关重要，因为只有与 "Password" 类型 一起存储时，它们才会被隐藏，如果转化为纯文本，它们将变得可读。

TeamCity 允许以多种方式解决类似的任务，在某些情况下，仍然优先创建不同的构建配置。 例如，如果在同一配置中有太多自定义运行，那么 TeamCity 预测每次构建的确切持续时间可能会更加困难。 如果您需要触发带有大量不同参数的构建，我们建议您创建一个 构建配置模板 ，并将其用作各种配置的蓝图，每种配置都有其自己的参数。

See also

Concepts

Administrator's Guide