Evidence项目中的Chromatic PR审查问题解决方案

在Evidence项目的持续集成流程中，团队发现了一个关于Chromatic UI测试的重要问题：当外部贡献者通过fork提交Pull Request时，Chromatic的GitHub Action无法正确检测到UI组件的变化。本文将深入分析问题原因并提供安全可靠的解决方案。

问题背景

在Evidence项目的开发流程中，团队使用Chromatic进行UI组件的可视化测试和审查。正常情况下，当开发者提交Pull Request时，GitHub Action会触发Chromatic测试，比较当前分支与主分支的UI差异。然而，当外部贡献者从fork的仓库提交PR时，这一机制出现了异常。

根本原因分析

问题的核心在于GitHub Action的安全机制。项目原本使用的是pull_request_target触发器，这种触发器出于安全考虑，会检出PR的目标分支（即主分支），而不是贡献者提交的变更分支。因此，Chromatic在比较UI变化时，实际上是在比较主分支与主分支自身，自然无法检测到任何差异。

安全考量

GitHub对pull_request_target触发器的这种设计是有意为之，目的是防止潜在的安全风险。如果直接运行外部贡献者的代码，可能会暴露仓库的敏感信息或执行恶意操作。因此，我们需要一种既能运行外部贡献者代码，又能保障仓库安全的解决方案。

解决方案

经过技术调研，我们采用了以下安全可靠的方案：

1. 修改checkout行为：在保持使用pull_request_target触发器的基础上，显式指定检出外部贡献者的分支代码。这通过覆盖checkout操作的ref参数实现。

2. 引入环境保护机制：创建一个需要维护者批准的特殊GitHub环境。当外部贡献者的PR触发Action时，系统会暂停执行并等待维护者的人工批准，确保代码经过审查后才运行。

实施细节

在具体实施时，我们需要注意以下几点：

• 明确区分内部贡献者和外部贡献者的PR处理流程
• 对于敏感操作（如访问密钥），必须放在需要批准的环境中执行
• 保持与现有CI/CD流程的无缝集成
• 确保解决方案不会给贡献者或维护者带来过多额外负担

额外优化

这一解决方案还带来了额外的好处：我们可以移除之前用于识别特定贡献者的白名单机制，转而使用更安全、更通用的环境保护方案。这不仅提高了安全性，还简化了工作流配置。

总结

在开源项目中，平衡安全性和贡献者体验是一个持续的挑战。通过GitHub的环境保护机制和适当的Action配置，Evidence项目成功解决了外部贡献PR的UI测试问题，同时保持了高标准的安全防护。这一方案不仅适用于Chromatic测试，也可以推广到其他需要处理外部贡献的安全敏感操作中。

对于其他面临类似问题的开源项目，这一解决方案提供了可借鉴的实践经验，展示了如何在保持项目安全的同时，为社区贡献者提供顺畅的协作体验。