允許使用者配置 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 進行持續整合。