允许用户配置 Build 失败的条件是很有用的功能，它是我们配置复杂 Build 流程的基础。TeamCity 为用户自定义 Build 失败条件提供了很好的支持。这些条件大体上可以分为两类，分别是：

基本的 Build 失败条件
高级的 Build 失败条件

基本的 Build 失败条件

打开 Build 的配置界面并选择 "Failure Conditions"，红框中的内容即 TeamCity 提供的基本 Build 失败条件：

设置超时时间

此选项设置 Build 最大执行时间，超过这个时间就停止 Build，并显示 Build 失败，并提示 timeout 错误：

这个选项主要处理 Build 被挂起的问题，同时能保正高效的使用 agent。

Build 过程返回非 0 值

默认选中，当 Build 程序返回了非 0 值时就把 Build 标记为失败。

检查 Build 中单元测试的结果

这个选项默认也是选中。只要有一个失败的单元测试就把 Build 标记为失败。但是并不会由于单元测试的失败而终止 Build 过程。如果没有选中这个选项，即便有单元测试失败 Build 也会被标记为成功。

检查日志中的错误消息

当检测到 Build 日志中含有出错的消息时把 Build 标记为失败。使用这个选项带来的问题是很容易造成误报。因为一些复杂的 Build 很难完全消除日志中的错误消息。

检测到内存溢出或崩溃

这个选项仅用于 Java 项目， 如果检测到 JVM 崩溃或者是 Java out of memory 问题就把 Build 标记为失败。

高级的 Build 失败条件

检测 Build 指标的变化

TeamCity 内置了一些度量指标，比如代码覆盖率、重复的代码等等。这里有一个很长的列表，当有搞不定的需求时，不妨看看，说不定会有意外的收获：

每次的 Build 都会生成这些度量指标。对于这些度量的指标我们可以为之指定一个阈值，一旦超标就把 Build 标记为失败。TeamCity 在这里支持两种比较方式：分别是与一个固定值对比和与另外一个 Build 对比：

默认选项是与一个固定值，比较有用的是下一个选项："value from another build"，即和某次 Build 的结果比：

这幅图中的配置说明：与最后一次 Pinned 的 Build 相比，如果产物的 Size 增大超过了 1%，Build 就失败。运行一下，如果失败，消息是这样的：

检测日志中的文本

日志的内容往往是最丰富的，并且很容易控制。因此通过检测日志的内容控制 Build 成功与否就变得十分重要。
TeamCity 能够对 Build 日志中的每一行进行文本匹配，并根据匹配的结果决定 Build 是成功还是失败。需要注意的是，在匹配时会忽略掉行开始处的日期和前缀等信息，因为这些信息并不是真正的 Build 消息。TeamCity 支持使用纯文本进行匹配，也支持 Java 格式的正则表达式进行匹配。匹配的选项可以选择包含指定的文本或者是不包含指定的文本。下图演示了一个文本类型检测：

如果发现日志中出现了文本 'Failed to restore plugin "cordova-plugin-x-socialsharing" from config.xml' 就让 Build 失败，并且显示消息 "restore cordova-plugin-x-socialsharing failed." TeamCity 更为贴心的是提供了测试失败条件的功能。点击 "Test on finished build"，并选择一个历史中的 Build 记录就可以了：

总结

如何判定 Build 成功/失败是相当重要的。 一般的 Build，使用 TeamCtiy 默认的配置基本就够用了。碰到复杂的场景，比如需要根据 Build 的结果来控制后续的执行流程时，就可以通过更高级的配置来完成任务。正是具备了这样的能力，我们才能够轻松的通过 TeamCity 进行持续集成。