私有依赖项 GitHub

此处描述的一些功能目前 仅适用于 travis-ci.com 上的私有仓库。

在测试私有仓库时，您可能需要通过 git 子模块、自定义脚本或依赖项管理工具（如 Bundler 或 Composer）将其他私有仓库作为依赖项引入。

Git 子模块必须在构建过程的早期阶段克隆，因此必须使用 部署密钥 或 用户密钥 方法。

如果依赖项也在 GitHub 上，则有四种不同的方法可以从 Travis CI VM 中获取仓库。每种方法都有其优点和缺点，因此请仔细阅读每种方法并选择最适合您情况的方法。

您可以使用 专用 CI 用户帐户 来执行除部署密钥方法之外的所有操作。这样可以将访问权限限制为定义明确的仓库列表，并确保访问权限为只读。

部署密钥 #

GitHub 允许您为仓库设置 SSH 密钥。这些部署密钥有一些很大的优势

• 它们不绑定到用户帐户，因此不会因从仓库中删除用户而失效。
• 它们不会访问其他不相关的仓库。
• 同一个密钥可用于存储在 GitHub 上的依赖项。

但是，使用部署密钥很复杂，因为 GitHub 不允许您重复使用密钥。因此，单个私钥无法访问多个 GitHub 仓库。

您可以为仓库中的每个依赖项包含不同的私钥，甚至可以 加密它们。以这种方式维护复杂的依赖项图可能很复杂且难以维护。出于这个原因，我们建议改为使用 用户密钥。

用户密钥 #

自定义 SSH 密钥目前 仅适用于 travis-ci.com 上的私有仓库。

您可以在 GitHub 上的用户帐户中添加 SSH 密钥。大多数用户可能已经这样做了，以便能够在本地克隆仓库。

这样，单个密钥可以访问多个仓库。为了限制仓库列表和访问类型，建议创建一个 专用 CI 用户帐户。

仓库设置 - 分叉 #

从 2022 年 3 月 1 日起，Git 分叉仓库的仓库安全设置可用。

对于 Git 仓库，您可以管理每个仓库在 Travis CI 中触发构建时如何处理 环境变量 和 自定义 SSH 密钥，这些构建是因从分叉仓库提交拉取请求而触发的。专门为此目的提供了两种设置，允许您自定义安全与协作设置。

• 基本仓库 - 由其他人分叉的 Git 仓库
• 分叉 或 分叉仓库 - 从 基本仓库 分叉的任何 Git 仓库
• PR - 拉取请求（例如，在 GitHub、BitBucket、GitLab 中）或合并请求（在 Assembla 中）

请注意：在 2022 年 3 月 1 日 之前在 Travis CI 中激活的仓库将 与分叉仓库（PR）共享加密环境变量 设置为 OFF。如有必要，请验证您的协作模型（尤其是对于公共仓库）。与分叉仓库（PR）共享 SSH 密钥 将针对私有仓库设置为 ON，以免破坏太多协作设置。对于在 2022 年 3 月 1 日 之后在 Travis CI 中激活的任何仓库，默认设置将设置为 OFF。对于在 Travis CI 中激活的仓库，您可能需要考虑根据您的协作模型更改默认设置。

与分叉仓库（PR）共享 SSH 密钥 #

请注意：‘与分叉仓库（PR）共享 SSH 密钥’ 仓库设置仅适用于 travis-ci.com 环境中的私有仓库。

此设置决定是否将 基本仓库 中的自定义 SSH 密钥与 分叉仓库 在分叉到基本仓库的拉取请求中共享（更改从分叉仓库合并到基本仓库）。在基本到基本仓库的拉取请求（更改从基本仓库合并到自身）的情况下，自定义 SSH 密钥将始终可用。

在分叉到分叉仓库的拉取请求（更改从分叉仓库合并到自身）的情况下，基本仓库的自定义 SSH 密钥将永远不可用。

在分叉到基本仓库的拉取请求中

• 如果此设置为 ON，则基本仓库的自定义 SSH 密钥将可供 分叉仓库 使用，这意味着分叉仓库中的构建将能够使用基本仓库的自定义 SSH 密钥。如果您的协作模型需要使用来自分叉仓库的拉取请求 (PR)，或者存在依赖项定义，这些依赖项依赖于来自 基本仓库 的 SSH 密钥，则请考虑将其设置为 ON。
• 如果此设置为 OFF 并且构建依赖于自定义 SSH 密钥（例如，用于获取某些其他依赖项），则构建将失败，并出现无访问权限错误。

请注意：在 travis-ci.com 中，秘密也可以存储在加密的环境变量中，这些环境变量可用于公共和私有仓库。详细了解 加密的环境变量。

使用现有密钥 #

假设

• 您正在为其运行构建的仓库名为“myorg/main”，它依赖于“myorg/lib1”和“myorg/lib2”。
• 您已在机器上设置了密钥，例如在 ~/.ssh/id_rsa 中（Unix 系统上的默认位置）。

您可以使用仓库设置添加新密钥。将 ~/.ssh/id_rsa 的内容粘贴到“私钥”文本字段中，并为其提供一个好的描述。

或者，您可以使用以下 CLI 命令将密钥添加到 Travis CI

$ travis sshkey --upload ~/.ssh/id_rsa -r myorg/main
Key description: Key to clone myorg/lib1 and myorg/lib2
updating ssh key for myorg/main with key from ~/.ssh/id_rsa
Current SSH key: Key to clone myorg/lib1 and myorg/lib2

如果您当前的工作目录是“myorg/main”仓库的克隆，则可以省略 -r myorg/main。

生成新密钥 #

假设

• 您正在为其运行构建的仓库名为“myorg/main”，它依赖于“myorg/lib1”和“myorg/lib2”。
• 您知道具有至少对所有三个仓库的读取访问权限的用户帐户的凭据。

travis 命令行工具可以为您生成一个新密钥并在 Travis CI 和 GitHub 上进行设置。为此，它将要求您提供 GitHub 用户名和密码。如果您刚刚创建了 专用用户 或如果您在机器上没有要使用的密钥，这非常方便。

这些凭据仅用于访问 GitHub，不会存储或共享给任何其他服务。

$ travis sshkey --generate -r myorg/main
We need the GitHub login for the account you want to add the key to.
This information will not be sent to Travis CI, only to api.github.com.
The password will not be displayed.

Username: ci-user
Password for ci-user: **************

Generating RSA key.
Uploading public key to GitHub.
Uploading private key to Travis CI.

You can store the private key to reuse it for other repositories (travis sshkey --upload FILE).
Store private key? |no|

Current SSH key: key for fetching dependencies for myorg/main

如果您当前的工作目录是“myorg/main”仓库的克隆，则可以省略 -r myorg/main。

在整个过程中，它会询问您是否要将生成的密钥存储在某个位置，通常在这种情况下去说“否”是安全的。毕竟，您可以根据需要生成新密钥。请参阅 下面的内容，了解有关存储和重复使用生成密钥的说明。

重复使用生成密钥 #

假设

• 您正在为其运行构建的仓库名为“myorg/main”，它依赖于“myorg/lib1”和“myorg/lib2”。
• 您知道具有至少对所有三个仓库的读取访问权限的用户帐户的凭据。
• 您只想生成一个密钥，以便可以轻松地撤销它或将其用于访问其他来源的依赖项或部署目标。

这是完全可选的，没有什么可以阻止您为所有正在测试的仓库生成新密钥。

您可以按照上面的步骤进行操作，但选择存储密钥。系统会要求您提供一个存储路径。

$ travis sshkey --generate -r myorg/main --description "CI dependencies"
We need the GitHub login for the account you want to add the key to.
This information will not be sent to Travis CI, only to api.github.com.
The password will not be displayed.

Username: ci-user
Password for ci-user: **************

Generating RSA key.
Uploading public key to GitHub.
Uploading private key to Travis CI.

You can store the private key to reuse it for other repositories (travis sshkey --upload FILE).
Store private key? |no| yes
Path: |id_travis_rsa| myorg_key

Current SSH key: CI dependencies

与往常一样，如果您的当前工作目录是“myorg/main”存储库的克隆，则可以省略-r myorg/main。

然后，您可以将密钥上传到 myorg/main2。

$ travis sshkey --upload myorg_key -r myorg/main2 --description "CI dependencies"
updating ssh key for myorg/main with key from myorg_key
Current SSH key: CI dependencies

从 travis 命令行工具的 1.7.0 版本开始，您可以将其与 repos 命令结合使用，不仅可以为“main”和“main2”设置密钥，还可以为“myorg”组织下的所有存储库设置密钥。

$ travis repos --active --owner myorg --com | xargs -I % travis sshkey --upload myorg_key -r % --description "CI dependencies"
updating ssh key for myorg/main with key from myorg_key
Current SSH key: CI dependencies
updating ssh key for myorg/main2 with key from myorg_key
Current SSH key: CI dependencies
updating ssh key for myorg/lib1 with key from myorg_key
Current SSH key: CI dependencies
updating ssh key for myorg/lib2 with key from myorg_key
Current SSH key: CI dependencies

请注意，如果您仍在使用travis-ci.org，则需要使用--org 而不是--com。

密码 #

假设

• 您正在为其运行构建的仓库名为“myorg/main”，它依赖于“myorg/lib1”和“myorg/lib2”。
• 您知道具有至少对所有三个仓库的读取访问权限的用户帐户的凭据。

要使用密码拉取依赖项，您需要在 Git HTTPS URL 中使用用户名和密码：https://ci-user:mypassword123@github.com/myorg/lib1.git。

或者，您也可以将凭据写入~/.netrc 文件。

machine github.com
  login ci-user
  password mypassword123

您还可以对密码进行加密，然后将其写入 .travis.yml 中的 before_install 步骤中的 netrc。

$ travis env set CI_USER_PASSWORD mypassword123 --private -r myorg/main

before_install:
- echo -e "machine github.com\n  login ci-user\n  password $CI_USER_PASSWORD" > ~/.netrc

也可以将凭据注入 URL，例如，在 Gemfile 中，它将如下所示

source 'https://rubygems.org.cn'
gemspec

if ENV['CI']
  # use HTTPS with password on Travis CI
  git_source :github do |repo_name|
    repo_name = "#{repo_name}/#{repo_name}" unless repo_name.include?("/")
    "https://ci-user:#{ENV.fetch("CI_USER_PASSWORD")}@github.com/#{repo_name}.git"
  end
end

gem 'lib1', github: "myorg/lib1"
gem 'lib2', github: "myorg/lib2"

对于私有 git 子模块，请注意 git submodule update --init recursive 命令在更新 ~/.netrc 凭据之前运行。如果您将凭据写入 ~/.netrc，请禁用子模块的自动加载，更新凭据，并添加一个显式步骤来更新子模块。

git:
  submodules: false
before_install:
  - echo -e "machine github.com\n  login ci-user\n  password $CI_USER_PASSWORD" >~/.netrc
  - git submodule update --init --recursive

API 令牌 #

假设

• 您正在为其运行构建的仓库名为“myorg/main”，它依赖于“myorg/lib1”和“myorg/lib2”。
• 您知道具有至少对所有三个仓库的读取访问权限的用户帐户的凭据。

此方法与上面概述的密码方法的工作方式相同，只是您使用的是 GitHub API 令牌，而不是用户名/密码对。

在要使用的用户的 GitHub 帐户设置中，导航到设置 > 开发者设置，然后生成一个“个人访问令牌”。确保令牌具有“repo”范围。

您的 ~/.netrc 应该如下所示

machine github.com
  login the-generated-token

您也可以直接在 URL 中使用它：https://the-generated-token@github.com/myorg/lib1.git。

使用 encrypt 命令将令牌添加到您的 .travis.yml 中。

$ travis env set CI_USER_TOKEN the-generated-token --private -r myorg/main

然后，您可以让 Travis CI 在每次构建时写入 ~/.netrc。

before_install:
- echo -e "machine github.com\n  login $CI_USER_TOKEN" > ~/.netrc

也可以将令牌注入 URL，例如，在 Gemfile 中，它将如下所示

source 'https://rubygems.org.cn'
gemspec

if ENV['CI']
  # use HTTPS with token on Travis CI
  git_source :github do |repo_name|
    repo_name = "#{repo_name}/#{repo_name}" unless repo_name.include?("/")
    "https://#{ENV.fetch("CI_USER_TOKEN")}@github.com/#{repo_name}.git"
  end
end

gem 'lib1', github: "myorg/lib1"
gem 'lib2', github: "myorg/lib2"

对于私有 git 子模块，请注意 git submodule update --init --recursive 命令在更新 ~/.netrc 凭据之前运行。如果您将凭据写入 ~/.netrc，请禁用子模块的自动加载，更新凭据，并添加一个显式步骤来更新子模块。

git:
  submodules: false
before_install:
  - echo -e "\n\nmachine github.com\n login $CI_USER_TOKEN\n" >~/.netrc
  - git submodule update --init --recursive

出于安全原因，.netrc 文件在克隆构建及其子模块执行的存储库后立即被删除！

专用用户帐户 #

如前所述，出于以下原因，创建专用 CI 用户可能很有意义。

• CI 用户只能访问您希望它访问的存储库。
• 您可以将访问权限限制为读取访问权限。
• 在泄漏密钥或凭据方面，风险更小。
• CI 用户不会因非技术原因离开组织，从而意外地破坏您的所有构建。

为此，您需要在 GitHub 上注册，就像您要注册普通用户一样。注册用户无法自动化，因为这将违反 GitHub 服务条款。