1

我已经安装了 SonarQube 7.6 Developer Edition，并开始在我的开发环境管道上使用它。我的编码方法是基于主干的开发。我们只有一条主线（主线或主线或您喜欢定义的开发，但只有一条主线）

实际上，代码上的所有更改都通过一个拉取请求，据我所知，SonarQube 被识别为一个短命的分支，只有这个硬编码规则被应用

错误条件：

  • 新打开的错误 > 0
  • 新的开放漏洞 > 0
  • 新的开放代码气味 > 0

这是我的质量门条件的一个子集。这意味着 PullRequest 可以通过质量门（因为像 Short-Lived Branch 一样被识别）并且当它合并到主线（主/主干）时应用我的质量门规则并且可能在合并时失败。

我怎么知道它是否在 PR 批准之前打破了质量门，或者更简单地说，如何将 Pull Request 识别为长寿分支？

在此处输入图像描述我试图将 * 定义为长寿分支模式，但它不起作用。附上截图。

4

1 回答 1

2

实际上，对于 SonarQube 7.6，这是状态：

  • 所有 PR 都遵循 Short-Lived Branch 的相同规则，目前无法设置临时质量门（或至少与项目相同），但计划在 Q12019 进行。更详细地说，PR 和 SLB 被认为是 2 个不同的东西，但它们在 SonarQube 中的表示是相同的。
  • 无法将 PR 识别为长寿分支（即使在长寿分支模式正则表达式中使用 *）。
  • 进入质量门的唯一方法是避免 PR 并在主线上启动合并，以检查质量门是否通过。

这里有 SonarQube 社区经理的回复

https://community.sonarsource.com/t/pull-request-analysis-and-quality-gate/6306/2

于 2019-01-31T10:07:24.040 回答