1

设置：

  • 私人主仓库，每个开发人员都有自己的私人分叉。
  • 目前使用 CircleCI，但我们很乐意切换以满足要求
  • 主仓库上的分支受到合并限制的保护

要求：

  • 构建 + 测试分叉的拉取请求
  • 根据 master repo 分支更新部署到不同环境
  • 并非所有开发人员都可以完全信任生产凭证

部分解决方案：

  • 在分叉的拉取请求上启用构建和传递秘密（参考）
  • 使用 CircleCI 上下文为每个分支设置环境变量。这允许不同的部署目标。

问题：

  • 任何可以打开 PR 的人现在都可以访问所有 repo 特定的秘密以及所有全局上下文。
  • 即使我们禁用基于分叉拉取请求的构建，任何对至少一个 repo 具有写访问权限的人都可以访问所有全局上下文。

问题：

  • 这似乎是一个非常常见的用例。其他公司是如何解决的？
  • CircleCI 不是解决此问题的正确工具吗？-不，不是（见下文）。
  • 我们应该建立一个定制的解决方案吗？

编辑1：

CircleCI 回复了我，令人惊讶的是这不是他们支持的用例。现在寻找其他供应商。上述问题仍未得到解答。

编辑2：

我还联系了 TravisCi 和 SemaphoreCi，似乎只有 TravisCi 支持构建分叉 PR 并且不向其中泄露秘密（参考）。

SempahoreCi 缺少 (1) 构建分叉 PR 和 (2) 在非主工作流的部署阶段隐藏秘密

CircleCi 具有受限的上下文，但它们需要手动更改工作流程。绝对不容易设置，我不完全理解它们将如何工作。

4

0 回答 0