其他分享
首页 > 其他分享> > Travis CI 配置文件 .travis.yml 的语法介绍和一些用法举例

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的原创文章,尽在:"汪子熙":

标签:CI,配置文件,app,travis,LXD,构建,yml
来源: https://www.cnblogs.com/sap-jerry/p/15779456.html