build 配置的名稱
作為描述資訊，description 會顯示在 build name 的後面：
我們可以為 build number 指定乙個格式。不同的使用者總是有不同的需求，如果您想要 build number 顯示為乙個自增的整數，就可以把 build number 指定為 %build.counter%。build.counter 是由 teamcity 來維護的，您也可以手動指定它。設定為 %build.counter% 的 build number format 看起來是這個樣子：
我們還可以指定為：
%build.vcs.number.%
或者%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 為我們提供了另外一些功能。
hanging build detection
探測掛起的 build，teamcity 能夠探測可能是被掛起的 builds。
什麼樣的 build 被認為是被掛起的 build 呢？當乙個 build 的執行時間明顯的超過了系統估計的平均執行時間，並且在超過預估時間後 build 也沒有發出過訊息，此時就認為 build 處於掛起狀態。teamcity 會把已經執行過的 build 時間取平均值，從而估算出平均執行時間。當我們訂閱通知時 teamcity 系統的通知時，可以把 掛起作為乙個條件。這樣當掛起發生時我們就會收到通知。
allow triggering personal builds
這個功能允許使用者使用未提交到**庫的**做build，但是需要開發工具的支援。
enable status widget
啟用狀態部件,這個選項讓我們可以獲得最後一次 build 的資訊，而不需要要使用認證資訊。需要注意的是，除了最後一次 build 的資訊，我們其實還可以獲得任何一次 build 的資訊。但是僅限於獲得 success/failure/internal error/cancelled 這幾種資訊。
我們可以通過不同的方式來獲得資訊，比如 html status widget 和 rest api。
下面我們看一下如何把 build 資訊嵌入到您的網頁上。
先啟用 「enable status widget」:
建立乙個 html 網頁，在 head 中加入：
在 body 中加入：
limit number of simultaneously running builds
設定乙個 build 可以同時執行的最大數。
主要是防止所有的 build agent 同時被乙個 build 全部用光。
出處：
TeamCity Build 版本控制系統配置
vcs 版本控制系統 是用來跟蹤專案原始檔版本變化的系統。它還有其它的名字，比如 scm 源 管理 當前 teamcity 內建支援的 vcs 型別有 git,subversion,mercurial,perforce,team foundation server,cvs,starteam,clea...
Android基本Http基本通訊
關於http通訊的其實自己也不是很懂，就是略微知道一些基本的通訊方法 方法1 建立http 客戶端 httpentity entity response.getentity 得到http的內容 response.getstatusline getstatuscode 得到http的狀態返回值 res...
基本形狀 基本 SVG 文件 2
定義和組 如前一頁中定義的多邊形和漸變，預定義項的實際用法通常有兩種形式。在這兩種形式下，定義的項都通過其本地 url 或 uri 引用。象 html 頁面一樣，id 屬性建立了文件中的乙個引用點。舉例說來，這意味著 uri irisgradient 引用標識為 irisgradient 的文件部分...