允許用戶配置 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 進行持續集成。