导入共享构建配置

选择加入
示例
导入源
从同一存储库导入配置
导入特定版本的配置
从私有存储库导入配置
共享加密密钥
条件导入
合并模式
导入优先级
常见问题

构建的主要配置来源是存储在您的存储库中的 .travis.yml 文件。您可以将共享配置片段导入到您的 .travis.yml 或 API 构建请求有效负载中，以更新多个存储库中的构建配置，只需更改一次即可。

导入的配置本身可以包含其他配置，这使得此功能具有很强的可组合性（循环导入将被跳过）。您最多可以导入 25 个构建配置片段。

BETA 构建配置导入功能目前处于测试阶段。请在社区论坛上留下反馈。

选择加入 #

为了激活此功能，您必须启用构建配置验证功能，该功能将在不久的将来推广到所有用户。

您可以在存储库的设置中启用构建配置验证，或者通过在您的 .travis.yml 文件中添加 version: ~> 1.0 来启用。

示例 #

与其在许多存储库的多个文件中指定要测试的 Ruby 版本，不如在共享片段中定义它们。

rvm:
  - 2.5
  - 2.6

然后，您可以将该片段 import 到您的 .travis.yml 中。以下配置从 travis-ci 帐户的 shared-configs 存储库的 main 分支中的 rubies.yml 文件导入。

import: travis-ci/shared-configs:rubies.yml@main
script: bundle exec rake

生成以下配置

rvm:
  - 2.5
  - 2.6
script: bundle exec rake

导入源 #

import 源的格式为 <account>/<repository>:<path>@<ref>，其中 <ref> 可以是任何有效的 Git 引用，例如提交 sha、分支名称或标签名称。

公共存储库可以从公共存储库导入源，但不能从私有存储库导入。私有存储库可以从公共和私有存储库导入源。有关更多信息，请参阅私有存储库。

导入单个源

import: travis-ci/build-configs:rubies.yml@main

# or

import:
  source: travis-ci/build-configs:rubies.yml@main

导入多个源

import:
  - travis-ci/build-configs:rubies.yml@adf1235
  - travis-ci/build-configs:other.yml@v1

# or

import:
  - source: travis-ci/build-configs:rubies.yml@adf1235
  - source: travis-ci/build-configs:other.yml@v1

默认情况下，合并模式 deep_merge_append 用于组合在导入配置和导入的配置中或在多个导入的配置中存在的键。您可以通过指定每个导入使用的合并模式来自定义它。有关合并模式的更多信息，请参见下文。

从同一存储库导入配置 #

当导入存储在与您的 travis.yml 相同存储库中的配置时，您可以省略 <account>/<repository> 部分。

# local imports fetch the same git commit ref
import:
- one.yml
- path/to/other.yml

路径相对于存储库的根目录。

导入特定版本的配置 #

对于从不同存储库导入的配置，默认情况下将使用存储库中默认分支的最新版本。

对于从同一存储库导入的配置，默认情况下将使用您当前正在构建的提交。这旨在帮助您创建和测试共享配置。

您可以使用任何有效的 Git 引用指定配置片段的确切版本。

import:
- one.yml@production
- travis-ci/build-configs/other.yml@v1.0.0

从私有存储库导入配置 #

为了从私有存储库共享配置，需要在该存储库中允许此操作，方法是在 更多选项 > 设置 > 配置导入 中启用“允许从此存储库导入配置文件”设置。

只有由同一组织或用户帐户拥有的私有存储库才能从私有存储库导入配置片段。无法将来自私有存储库的配置导入到来自公共存储库的配置中。

包含在导入的配置片段中的加密密钥可以与由同一组织或用户帐户拥有的存储库共享和解密。

可以将来自公共存储库的配置导入到由不同组织或用户帐户拥有的其他公共存储库的配置中，但这些导入的配置中包含的加密密钥将无法访问。

条件导入 #

配置导入可以携带一个条件，该条件指定在什么情况下应包含导入的配置。

例如，使用此配置，本地文件 .travis/master.yml 将在 master 分支上构建时导入，而 .travis/other.yml 将在所有其他构建中导入。

import:
- source: .travis/master.yml
  if: branch = master
- source: .travis/other.yml
  if: branch != master

有关条件语法的完整规范，请参阅条件。

合并模式 #

合并模式控制如何将导入的配置合并（组合）到导入的配置中。可以为每个导入的配置源指定不同的合并模式。

有以下合并模式

deep_merge_append（默认）
deep_merge_prepend
deep_merge
merge

默认合并模式是 deep_merge_append。

深度合并追加/预置 #

合并模式 deep_merge_append 和 deep_merge_prepend 递归地合并保存映射（哈希）的部分（键），并通过追加或预置到导入配置中的序列来连接序列（数组）。

import:
- source: one.yml
  mode: deep_merge_append
- source: other.yml
  mode: deep_merge_prepend

深度合并 #

合并模式 deep_merge 递归地合并保存映射（哈希）的部分（键），但会覆盖序列（数组）。

import:
- source: one.yml
  mode: deep_merge # deep merge

此模式首先将您的 .travis.yml 内容合并到 one.yml 文件中（即，如果使用合并模式 deep_merge，则 .travis.yml 文件中的“win”项目将覆盖 one.yml 中相应级别的键）。

分别

import:
  - source: one.yml
  mode: deep_merge # deep merge
  - source: two.yml
  mode: deep_merge # deep merge

此模式首先将您的 .travis.yml 内容合并到 one.yml 文件中（如果需要，将 one.yml 中的部分替换为来自 .travis.yml 的内容）。结果将合并到 two.yml 文件中（同样，由于此处指定了 deep_merge 模式，因此先前合并的结果将覆盖此文件中的内容）。

这样做的原因是在许多情况下，当您将某些内容导入到您的 .travis.yml 文件时，您希望能够使用 .travis.yml 文件中的配置覆盖或自定义该导入的配置。

合并 #

合并模式 merge 执行浅合并。

这意味着在您的 .travis.yml 中定义的根级部分（键）将覆盖导入文件中也存在的根级部分（键）。

import:
- source: one.yml
  mode: merge # shallow merge

导入优先级 #

通过 Travis API 或 Web UI 触发构建时，升序优先级的顺序为

如果给出，则来自 API 构建请求有效负载的配置
如果给出，则来自 API 构建请求有效负载的导入配置，按列出顺序（如果这些导入的配置导入其他配置，则遵循深度优先搜索模式）
来自 .travis.yml 的配置
来自 .travis.yml 的导入配置，按列出顺序（如果这些导入的配置导入其他配置，则遵循深度优先搜索模式）。

常见问题 #

我可以在特定作业级别导入共享构建配置吗？ #

不，解析后的 YAML 树必须合并。因此，import 关键字仅在根级别被接受。如果适合您的场景，您可以将作业模板指定在例如 job.yml 中，并使用 mode: deep_merge 将其导入到您的 .travis.yml 中，并在导入的模板中添加要覆盖的 .travis.yml 特定内容。

是否可以通过共享配置机制创建和使用锚点？ #

不幸的是，不支持。尽管我们鼓励使用 YAML 作为构建配置语言，但锚点和别名（引用这些锚点）必须在一个 .yml 文件中定义和使用，并且会在任何 import 操作（合并解析树）发生之前展开。出于同样的原因，尝试在 .travis.yml 中将锚点分配给导入的键将不起作用——在合并操作发生之前，必须先解析 .travis.yml 和 imported.yml。

另请参阅 native-api 在社区论坛中的简洁说明