溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
在 TeamCity 中創建了一個項目 HelloApp，并在這個項目中創建了一個名為 HelloAppDailyBuild 的Build 用來編譯 demo 程序。本文我們將詳細介紹 Build 中的基本配置。下圖是 Build 基本配置的概覽：
Build 配置的名稱。
Build configuration ID: 在系統中標識該 Build 配置，自動生成的規則是：項目名稱 +下劃線 + build 配置名稱。
比如要導航到一個 build 配置的頁面， URL為：
http://xxxx/viewType.html?buildTypeId=HelloApp_HelloAppDailyBuild
最后一個參數就是 Build configuration ID。這個ID非常重要，我們使用 urls, REST API 向服務器請求信息時，都要使用它。在服務器上，它還作為一些配置文件的目錄名稱。
作為描述信息，Description 會顯示在 build name 的后面：
我們可以為 build number 指定一個格式。不同的用戶總是有不同的需求，如果您想要 build number 顯示為一個自增的整數，就可以把 build number 指定為 %build.counter%。build.counter 是由 TeamCity 來維護的，您也可以手動指定它。設置為 %build.counter% 的 build number format 看起來是這個樣子：
我們還可以指定為：
%build.vcs.number.<VCS_root_name>%
或者
%property.name%
這些都是 TeamCity 維護的一些變量。一個完整的例子看起來像這個樣子 :
1.0.%build.counter%.%build.vcs.number.My_Project_svn%
注意，最好是保持 build number 的唯一性。所以應該把 build counter 加入到 build number format 中。
如果想用日期做 build number 該怎么辦，如果還要顯示 build 在每天中的序號呢？遺憾的是默認情況下我們沒辦法完成這樣的需求，但是 TeamCity 提供了很好的擴展能力。我們可以寫一個插件了實現這樣的功能：
Build 次數的計數器，您也可以手動設置它。但您做好清楚的知道自己在干什么。
收集 build 產物需要通過指定 Artifact paths 來完成。我們可以把產物的路徑分為兩類：準確的路徑和通過模式匹配獲得的路徑。
如果您知道 build 產物的準確路徑，就可以直接寫產物的路徑。
還可以通過 teamcity 的工具進行選擇：
可以通過新行或者逗號來分隔不同的模式匹配規則如：
[+:]source [=> target]
這個規則把滿足條件的文件加入到產物中。
-:source [=> target]
這條規則則是把滿足條件的文件從產物中移除。
方括號圍起來的參數是可選的。規則根據右面的部分進行分組，根據出現的順序依次起作用，如：
+:**/* => target_directory -:**/folder1 => target_directory
表示除了 folder1 下的內容，把其他所有內容加入到產物中。
下面是詳細的格式 :
file_name|directory_name|wildcard [ => target_directory|target_archive ]
file_name 指定產物文件相對于 build checkout directory 的路徑。
directory_name 指定某個目錄相對于 build checkout directory 的路徑。目錄下的所有文件和子目錄都會被作為產物。產物中文件在目錄中的結構保持不變。但是目錄 directory_name 本身并不包含在產物中。
wildcard(通配符) 收集符合 Ant-like 的通配符匹配的文件作為產物 (僅支持 "*" 和 "**")。通配符要出現在相對于 build checkout directory 的路徑中。符合條件的文件在產物中的路徑會保持原來的路徑結構。
還可以在收集產物的規則中使用參數。參數可以是 TeamCity 內置的變量也可以是用戶自己定義的變量。
=> 后面的部分是可選的。=> 后面跟的目錄名可以用來指定產物文件所存放的目錄。
如果沒有設置目標目錄，那么產物會被放置在 build 產物的根目錄下。
注意，目標路徑不能是絕對路徑。非相對的路徑會在build時產生錯誤。
target_directory 收集的產物文件會被放到這個目錄下。
target_archive 把產物打包后歸檔文件的路徑。支持的歸檔文件格 式有 .zip，.7z，.jar，.tar.gz，.tgz。
下面是一些常用的例子：
install.zip // 把 build checkout directory 目錄下的所有文件放入壓縮包 install.zip 作為產物。
dist // 收集 build checkout directory\dist 目錄下的所有內容作為產物。
target/*.jar // 收集 build checkout directory\target 目錄下的所有 jar 文件作為產物。
target/**/*.txt => docs // 收集 build checkout directory\target 目錄及其子目錄下所有的 .txt 文件 作為產物。并把這些文件全部放入目標目錄 docs 中。
reports => reports, distrib/idea*.zip // 把 build checkout directory\reports 目錄中的內容放入產物中的 reports 目錄下。 // 把 build checkout directory\distrib 目錄下符合 idea*.zip 條件的文件放到產物的根目錄下。
// 我們還可以指定產物在 zip 歸檔文件中的位置，如： results\result1\Dir1\Dir2 => archive.zip!results/result1/Dir1 // Dir2 目錄中的內容將添加到歸檔文件中的 results/result1/Dir1 目錄下。
// 產物中相同的歸檔文件名稱可以被使用多次，如: +:*/*.html => report.zip +:*/*.css => report.zip!/css/ -:*/*.txt => report.zip
Build options 為我們提供了另外一些功能。
探測掛起的 build，TeamCity 能夠探測可能是被掛起的 builds。
什么樣的 build 被認為是被掛起的 build 呢？當一個 build 的執行時間明顯的超過了系統估計的平均執行時間，并且在超過預估時間后 build 也沒有發出過消息，此時就認為 build 處于掛起狀態。TeamCity 會把已經運行過的 build 時間取平均值，從而估算出平均運行時間。當我們訂閱通知時 TeamCity 系統的通知時，可以把 掛起作為一個條件。這樣當掛起發生時我們就會收到通知。
這個功能允許用戶使用未提交到代碼庫的代碼做build，但是需要開發工具的支持。
啟用狀態部件,這個選項讓我們可以獲得最后一次 build 的信息，而不需要要使用認證信息。需要注意的是，除了最后一次 build 的信息，我們其實還可以獲得任何一次 build 的信息。但是僅限于獲得 success/failure/internal error/cancelled 這幾種信息。
我們可以通過不同的方式來獲得信息，比如 HTML status widget 和 REST API。
下面我們看一下如何把 Build 信息嵌入到您的網頁上。
先啟用 “enable status widget”:
創建一個 html 網頁，在 head 中加入：
<style type="text/css">@import "<TeamCity_server_URL>/css/status/externalStatus.css";</style>
在 body 中加入：
<script type="text/javascript" src="<TeamCity_server_URL>/externalStatus.html?js=1&buildTypeId=xxx"></script>
請用您的 TeamCity 服務器地址更換上面字符串中的占位符，并且用有意義的 Build configuration ID 替換 xxx。然后在瀏覽器中打開看看：
設置一個 build 可以同時運行的最大數。
主要是防止所有的 build agent 同時被一個 build 全部用光。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
