Travis CI 配置文件 .travis.yml 的语法介绍和一些用法举例

在 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: heroku
  api_key: ...
  app: app-production
  on:
    branch: master
- provider: heroku
  api_key: ...
  app: app-staging
  on:
    branch: staging

使用下列的语法，重用某块 yaml 定义：

deploy:
- &deploy
  provider: heroku
  api_key: ...
  app: app-production
  on:
    branch: master
- <<: *deploy
  app: app-staging
  on:
    branch: staging

更多Jerry的原创文章，尽在："汪子熙":