在 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 |
|