设置：
- 私有主仓库，每个开发人员都有自己的私有fork。
- 当前使用CircleCI，但我们很乐意切换以满足要求
- 主存储库上的分支受到合并限制的保护
要求：
- 对派生的拉取请求进行构建+测试
- 根据主存储库分支更新部署到不同的环境
- 并非所有开发人员都能获得生产凭据的完全信任
部分解决方案：
- 在派生的拉取请求（Reference）上启用构建和传递机密
- 使用CircleCI上下文为每个分支设置环境变量。这样可以实现不同的部署目标。
问题：
- 任何能够打开PR的人现在都可以访问所有特定于仓库的秘密以及所有全局上下文。
- 即使我们禁用了基于派生拉取请求的构建，任何对至少一个存储库具有写访问权限的人都可以访问所有全局上下文。
问题：
- 这似乎是一个非常常见的用例。其他公司如何解决呢？
- CircleCI是否不是正确的工具？ -不，不是（请参见下文）。
- 我们应该构建自定义解决方案吗？
编辑1：
CircleCI回到我身边，令人惊讶的是，这不是他们支持的用例。现在正在寻找其他提供商。以上问题仍然没有答案。
编辑2：
我还联系了TravisCi和SemaphoreCi，看来只有TravisCi支持构建派生的PR，并且不会向其中泄漏机密（Reference）。
SempahoreCi缺少（1）建立分叉的PR，（2）在非主工作流程的部署阶段隐藏秘密
CircleCi有restricted contexts，但它们需要手动更改工作流程。绝对不容易设置，而且我不完全了解它们的工作原理。