在 Github 專案資料夾下面新增 .travis.yml 檔案。

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

一個例子：

![](https://img-blog.csdnimg.cn/img_convert/544abd7a173fbc18d18162eadefed0aa.png)

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

這個 .travis.yml 配置檔案的語法在[官網](https://config.travis-ci.com/)可以找到。

比如，dist: bionic 的意思是，[構建虛擬系統的型別](https://docs.travis-ci.com/user/reference/overview/#virtualization-environments)，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](https://config.travis-ci.com/ref/job/branches) 關鍵字和 only 的組合，下列例子的語義是，僅當 develop, epic, release, integration-libs 等 分支出現程式碼提交時才觸發 Travis.

![](https://img-blog.csdnimg.cn/img_convert/526cd3732a1a9558d37fc9e1dc6712d8.png)

.travis.yml 是一個 YAML 格式的配置檔案，下面是一些[高階用法](https://docs.travis-ci.com/user/build-config-yaml)。

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

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

```yaml
deploy:
- provider: heroku
  api_key: ...
  app: app-production
  on:
    branch: master
- provider: heroku
  api_key: ...
  app: app-staging
  on:
    branch: staging
```

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

```yaml
deploy:
- &deploy
  provider: heroku
  api_key: ...
  app: app-production
  on:
    branch: master
- <<: app:="" app-staging="" on:="" branch:="" staging="">
                        </:>

Travis CI 配置檔案 .travis.yml 的語法介紹和一些用法舉例

相關文章