在 Github 項目文件夾下面添加 .travis.yml 文件。

為了運行構建，Travis CI 的系統將觸發構建的存儲庫克隆到構建環境。 構建環境是一個隔離的虛擬機或 LXD 容器，一旦構建完成就會終止。 克隆僅在構建請求之后發生，因此僅適用于在 GitHub 設置中明確啟用的存儲庫。

一個例子：

為了設置構建環境并準備構建，Travis CI 的系統從存儲庫和構建請求中明確指定的分支中獲取并處理 .travis.yml 配置文件，由 GitHub 觸發。

這個 .travis.yml 配置文件的語法在官網可以找到。

比如，dist: bionic 的意思是，構建虛擬系統的類型，bionic 是其中一個枚舉值。

Travis CI 支持 Linux 構建的兩種虛擬化類型：“Full VM”和“LXD”。 最重要的是，Linux 構建可以在多個 CPU 架構上運行。

Full VM 是啟用 sudo 的，每個構建的完整虛擬機，運行 Linux.

雖然啟動緩慢（與 LXD 容器相比增加了構建時間）但沒有任何限制。

它分配了固定數量的 vCPU 和 RAM。

而 LXD 環境，盡可能接近容器世界中的虛擬機。 Linux 環境在非特權 LXD 容器中運行。

和 Full VM 相比，其啟動速度更快（與完整 VM 相比減少了構建時間）但確實存在一些限制。

它從最少 2 個 vCPU 開始，如果有更多的計算時間可用，主機可以動態分配它以加快構建速度。

又比如 branches 關鍵字和 only 的組合，下列例子的語義是，僅當 develop, epic, release, integration-libs 等 分支出現代碼提交時才觸發 Travis.

.travis.yml 是一個 YAML 格式的配置文件，下面是一些高級用法。

在更高級的用例中，為了減少大型構建配置文件中的重復，一個好的做法是使用 YAML 的機制來定義和重用共享配置部分作為 YAML 錨點和別名。

例如，不要像這樣為兩個不同的部署目標重復部署配置, 這是不好的實踐：

deploy: - provider: herokuapi_key: ...app: app-productionon:branch: master - provider: herokuapi_key: ...app: app-stagingon:branch: staging

使用下列的語法，重用某塊 yaml 定義：

deploy: - &deployprovider: herokuapi_key: ...app: app-productionon:branch: master - <<: *deployapp: app-stagingon:branch: staging

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的Travis CI 配置文件 .travis.yml 的语法介绍和一些用法举例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。