配置 VCS 触发器
每当 TeamCity 检测到配置的 VCS roots 中有新的更改时，VCS 触发器会自动启动新的构建，并在待处理的更改中显示该更改。 可以在构建配置中添加多个 VCS 触发器。
默认设置的新 VCS 触发器在构建配置中有待处理的更改时触发构建：根据 VCS 根的 检查更改的间隔 对版本控制进行轮询，以便尊重配置的 VCS 提交挂钩。 仅显示与检出规则匹配的更改作为待处理，因此触发器会处理这些更改。 如果在短时间内进行了多次签入，并被 TeamCity 发现，则只会触发 一个构建。
在检测到最后一次更改后，可以配置一个 安静期，在构建进入队列前等待一段没有更改的时间。
两个选项的全球默认值都是60秒，可以在 Administration | Global Settings 页面为服务器进行配置。
在快照依赖性发生变化时触发构建
如果您有一个构建链（即通过快照依赖性相互连接的一系列构建），触发器应配置在链中的最终构建中。 这就是下图中的 pack setup。
VCS 构建触发器还有另一个 选项，可以改变构建链的触发行为。 启用此选项后，即使在依赖项中检测到更改，而不是在最终构建中，整个构建链也将被触发。
让我们从示例中取出一个构建链： pack 设置—— 依赖于 —— 测试—— 依赖于 —— 编译。
在 pack 设置 配置中设置了 VCS 触发器后，当 TeamCity 检测到在 pack 设置 中的变更时，整个构建链通常会被触发；在 编译 中的变更只会触发 编译 ，而不会触发整个链条。 如果您希望在 编译 中的 VCS 更改触发整个链，将带有 "在快照依赖中的更改上触发" 选项 的 VCS 触发器添加到链的最终构建配置 pack 设置。 这不会改变构建执行的顺序，但只有在任何快照依赖项发生变化时，才会触发整个构建链。 在此设置中， 编译 或 测试 构建配置不需要 VCS 触发器。
如果指定了触发规则（下面详述），则这些规则将适用于所有的更改（包括来自快照依赖的更改），只有符合规则的更改才会触发构建链。
请参阅 构建依赖项 页面上的详细信息。
每次签入触发
当此选项未启用时，可以由不同的提交者进行多次检入；一旦它们被检测到，TeamCity 将只将一次包含所有这些更改的构建添加到队列中。
如果您拥有快速的构建环境和足够的构建代理，您可以让 TeamCity 为每次检入启动新的构建 对于每次检入，确保没有其他更改进入相同的构建。
要做到这一点，请选择 每次检入时触发构建 选项。 如果您选择了 如果来自同一提交者，则在构建中包含多个检入 选项，TeamCity 将检测到一些待处理的更改，它将根据用户分组并开始只具有单个用户更改的构建。
这有助于找出是谁的更改导致构建失败或引发新的测试失败，如果出现这样的问题的话。
静默期设置
通过指定静默期，您可以确保在由多个 VCS 检入组成的非原子检入中间不会触发构建。
一段 静默期 是 TeamCity 在检测到最后一次 VCS 更改和将构建加入队列之间维护的一段时间（以秒为单位）。 如果在构建配置期间检测到新的 VCS 变更，那么该期间将从新变更检测时间开始重新计算。 只有在静默期内未检测到新的 VCS 变更时，构建才会被添加到队列中。
请注意，实际的静默期不会少于构建配置的 VCS 根目录中最长的 检查更改间隔，因为 TeamCity 必须确保在静默期间至少收集一次更改。
安静期可以设置为默认值（60秒，可以在Administration | Global Settings页面全局更改）或为构建配置设置自定义值。
构建队列优化设置
默认情况下，TeamCity 优化构建队列：已排队的构建可以被已开始的构建或更近期的排队构建所替换。 您可以通过取消勾选相应的框来禁用此默认行为。
VCS 触发规则
如果未指定触发规则，那么一旦检测到构建配置的任何更改，就会触发构建。 您可以通过更改 VCS 根设置并指定 checkout rules 来控制检测到的更改。
为限制触发构建的更改，请使用 VCS 触发规则。 您可以在文本区域中手动添加这些规则（每行一条），或者使用添加新规则按钮来生成它们（如有必要，向下滚动以显示按钮）。
每条规则要么是"包含"（以 + 开始），要么是"排除"（以 - 开始）。
一般语法
单个规则的一般语法是：
where:
Ant_like_wildcard：用来匹配已更改文件路径的 通配符。 仅支持*和**模式，不支持?模式。 规则中的文件路径可以是相对路径（不以/或\开头），以匹配代理上的结果路径，或者是绝对路径（以/开头），以匹配相对于 VCS 根的 VCS 路径。 对于更改中的每个文件，都会找到最具体的规则（匹配最长文件路径的规则）。 如果有至少一个文件与“include”规则匹配，或者文件没有与“exclude”规则匹配，那么将触发构建。VCS_username：如果指定，将规则限制为只适用于由具有相应的 VCS 用户名 的用户所做的更改。VCS_root_id：如果指定了，该规则将仅限于对应的 VCS 根目录的更改。VCS_comment_regexp：如果指定，则只限于在 VCS 注释中包含指定文本的更改。 请使用 Java 正则表达式 模式匹配注释中的文本（请参见下面的示例）。 如果注释文本包含匹配的文本部分，该规则则匹配；要匹配整个文本，请包含^和$特殊字符。
触发规则示例
示例 | 描述 |
|---|---|
+:. | 包含所有文件 |
-:**.html | 排除所有 |
-"：user=techwriter;root=InternalSVN:/misc/doc/*.xml | 排除由 |
-:lib/** | 阻止由于对构建源代码的 |
-:comment=minor:** | 如果更改检查包含注释中的单词 |
-:comment=^oops$:** | 如果注释仅由 |
+":comment=#teamcity:** | 如果评论包含 |
+":comment=(?s)#teamcity.*#major:** | 如果评论中同时包含了 例如，以下的注释将会触发构建： #teamcity the first line
#major the second line |
分支过滤器
在 Branch Filter 中阅读更多内容。
触发规则和分支过滤器的组合
触发规则和分支过滤器通过 AND 联合，这意味着构建只有在 两个条件都满足 的情况下才会触发。
例如，如果您在触发规则字段中指定了评论文本，并提供了分支规格说明，那么只有当提交包含特殊文本，并且符合分支筛选器的分支时，才会触发构建。
在分支合并时触发构建
VCS 触发器完全了解分支，并且一旦在分支中检测到检入，就会触发构建。
当从一个分支合并 / 快速前进到另一个分支时，严格来说代码中实际上没有任何变化。 默认情况下，VCS 触发器的行为如下：
当合并/快速向前的两个非默认分支时：构建中的更改会根据同一分支中的先前构建进行计算，所以如果在不同的分支中有相同的提交构建，触发器会在指向同一提交的另一分支中启动构建。
如果默认分支是合并/快速向前的分支之一，更改始终依据默认分支计算，如果在默认分支中有相同修订的构建，那么 TeamCity 将不会在同一修订上运行新的构建。
触发构建自定义
触发器设置中的 Build Customization 标签允许配置由此触发器启动的构建的自定义参数。 与 Run Custom Build 对话框类似，它让您可以覆盖 构建参数 的值，并选择是否在构建前清理 检出目录。
在此选项卡中，您可以自定义当前构建配置中使用的任何参数的值。 或者，您可以添加一个新的参数，它将仅在由此触发器启动的构建中可用。 如果当前构建对其他构建有快照依赖，这样一个参数也可以用来覆盖依赖构建配置的某个属性：使用这个 reverse.dep.<dependencyBuildID>.<property> 语法。
请注意，如果您在触发器中重新定义了构建参数，然后在 参数 中删除了原始参数，那么它的重新定义值将被转换为触发器自己的纯文本参数。 在定制安全值时，这一点至关重要，因为只有与 "Password" 类型 一起存储时，它们才会被隐藏，如果转化为纯文本，它们将变得可读。
TeamCity 允许以多种方式解决类似的任务，在某些情况下，仍然优先创建不同的构建配置。 例如，如果在同一配置中有太多自定义运行，那么 TeamCity 预测每次构建的确切持续时间可能会更加困难。 如果您需要触发带有大量不同参数的构建，我们建议您创建一个 构建配置模板，并将其用作各种配置的蓝图，每种配置都有其自己的参数。