使用 YAML 作为构建配置语言

YAML 锚点和别名的用法
私钥作为 YAML 锚点和别名以及外部工具
版本号

Travis CI 使用 YAML 作为构建配置的主要语言，存储在主 .travis.yml 构建配置文件中，以及使用构建配置导入功能导入的其他配置源。

此页面记录了有关 Travis CI 如何使用 YAML 的一些值得注意的信息。

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

私钥作为 YAML 锚点和别名以及外部工具 #

在某些情况下，最好在不同的位置定义共享的 YAML 配置部分，而不是在使用它的位置定义，例如为了提高可读性。

例如，可以通过重用共享的 YAML 部分来定义多个作业，如下所示

_shared_job: &shared_job
  script: echo "shared script config"
  # ...
jobs:
  include:
  - name: Job 1
    <<: *shared_job
  - name: Job 2
    <<: *shared_job

根据 Travis CI 的构建配置架构，额外的键 _shared_job 是一个未知键。在其他情况下，一些用于 Travis CI 的外部工具依赖于在 Travis CI 的构建配置文件中存储配置，也添加了未知键。

建议使用下划线作为前缀，将其标记为私有配置键，避免与将来添加到构建配置架构中的键发生可能的命名冲突。

版本号 #

Travis CI 曾经使用了一个简单的 Ruby YAML 解析器来解析作为 YAML 给出的构建配置，很长时间。这导致以 YAML 数字形式给出的版本号有时会以意外的方式被截断。反过来，我们的文档以及许多外部文章和帖子建议引用版本号，以便 YAML 解析器将其解释为字符串。

这不再适用，如果功能构建配置验证对于给定的存储库处于活动状态。

例如，指定 Node.js 版本为 node_js: 9.10 将被解析为 9.0，与预期版本不匹配。作为解决方案，我们建议改为指定 node_js: "9.10"。

随着作为构建配置验证功能的一部分引入新的 YAML 解析器，不再需要此操作，因为此解析器将 YAML 数字转换为 Ruby 字符串，只有在我们的构建配置架构需要时才会在稍后进行类型转换。