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

在 Github 项目文件夹下面添加 .travis.yml 文件。
为了运行构建,Travis CI 的系统将触发构建的存储库克隆到构建环境。 构建环境是一个隔离的虚拟机或 LXD 容器,一旦构建完成就会终止。 克隆仅在构建请求之后发生,因此仅适用于在 GitHub 设置中明确启用的存储库。
一个例子:
Travis|Travis CI 配置文件 .travis.yml 的语法介绍和一些用法举例
文章图片

为了设置构建环境并准备构建,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|Travis CI 配置文件 .travis.yml 的语法介绍和一些用法举例
文章图片

.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

【Travis|Travis CI 配置文件 .travis.yml 的语法介绍和一些用法举例】更多Jerry的原创文章,尽在:"汪子熙":
Travis|Travis CI 配置文件 .travis.yml 的语法介绍和一些用法举例
文章图片

    推荐阅读