在 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的原创文章，尽在："汪子熙":
网友评论