在查看我最近的问题时 Sonarcloud failure with Travis, Maven & github我意识到我问错了问题。我试图解决症状而不是根本问题。
我从事的一个项目 (eclipse/scanning) 使用 Github 作为其存储库，使用 Travis 和 Sonarcloud 进行持续集成和代码分析。
虽然 Sonarcloud 分析在内部拉取请求(来自分支的拉取请求直接推送到 eclipse/scanning)上运行良好，但在 Travis 为外部拉取请求(来自 fork 存储库的那些)运行时不起作用。
潜在的问题是，我们目前运行 sonarcloud 的方式依赖于环境变量，出于安全原因，这些环境变量未填充用于外部拉取请求:
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
我们将存储库设置为不关心 Sonarcloud 是否运行，但这意味着我们经常合并违反 sonarcloud 规则的更改，因为我们没有意识到它们已被破坏。我们只看到这些规则在下次被直接推送到存储库的人更改时被打破。这将修复 Sonarcloud 发现的问题的负担从合作者转移到了提交者。
所以，
- 有没有办法在不引入安全问题的情况下启用 Sonarcloud 分析来自 fork 存储库的拉取请求？
请注意，这个问题似乎超出了In Travis Public Repository how to add a Secure variable that works on Pull requests too 的范围。还没有答案。
最佳答案
这可能不是您正在寻找的简单解决方案，但我认为在构建拉取请求时没有更简单的方法来访问 secret ，除非 Travis 以某种形式添加对它的支持。毕竟， secret 变量不可用是有充分理由的，因为拉取请求可以包含在构建期间执行的任意代码。攻击者可能会使用它来创建一个拉取请求，该请求会更改构建过程以读取解密的环境变量并将它们发送给他。
根本问题是运行构建的代码和构建的代码来自相同的(有时是不受信任的)源。为了能够在构建过程中使用 secret ，构建的代码和构建的代码需要分开，并且构建代码需要来自受信任的来源。不得执行来自不受信任来源的任何代码，除非它被沙盒化以使其无法访问任何 secret 。
据我所知，Travis 没有提供实现此目的的标准方法。
通过遵循将构建代码和正在构建的代码分离的想法，仍然应该可以针对外部拉取请求执行 Sonarqube 分析。
第一步是在 Github 上创建一个新的存储库“构建代码”，其中仅包含受信任的构建脚本。这些脚本负责检查拉取请求并执行 Sonarqube 分析。由于这些不是外部拉取请求的一部分，它们可以访问 secret 变量。但是请注意，不要在拉取请求中运行单元测试，因为这些是不受信任的。
第二步是每当针对实际源代码存储库发出拉取请求时触发“构建代码”存储库的构建。 Travis 提供了一个 API to trigger builds .但是，这也需要一个 secret 。因此，我们不能在构建拉取请求时简单地触发“构建代码”存储库的构建。但是，我们可以做的是安装 webhook在 Github 上的源代码存储库上，它在发出拉取请求时调用一个小型 Web 服务。然后该服务调用 Travis API 来触发可信构建代码库的构建。
我希望这是有道理的。如果有什么不清楚的地方请告诉我。
我自己还没有这样做。所以我不能提供任何代码。但我认为设置一个小型 Web 服务将 Webhook 从 Github 请求转换为 Travis 的构建请求应该不会太难。
关于java - 如何让 Sonarcloud 在来自带有 Travis、Maven 和 github 的 fork 的拉取请求上运行，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45612758/