【问题标题】:Update violation threshold limits via Sonar REST API通过 Sonar REST API 更新违规阈值限制
【发布时间】:2013-11-21 05:02:50
【问题描述】:

在我正在工作的项目中,我们使用 Sonar 来提高代码质量和测试覆盖率。我们已将错误阈值设置为我们当前的违规数量和测试覆盖率。

现在我想使用 Sonar 的 REST API 来更新阈值。假设我们目前有 10 次严重违规。 1 个违规已修复,严重违规数量减少到 9 个。我现在想使用 Sonar 的 REST API 自动调整阈值。我已经设法通过 /api/resources URL 通过 REST API 检索违规和测试覆盖率的当前值,请参阅link

我搜索了 Web 服务文档,但找不到任何可用于更新错误阈值的 REST URL。

有可能吗?

最好的问候/Lasse

【问题讨论】:

    标签: api rest url sonarqube threshold


    【解决方案1】:

    从我的角度来看,这不是正确的方法。您应该设置差异警报(即没有新的阻止程序问题,新代码的代码覆盖率应至少为 80% 等)。基线可以是您开始遵循这些要求的日期。

    【讨论】:

    • 很棒的输入。谢谢!我们将尝试开始使用它。我脑海中浮现的一个问题是:如果您使用您所描述的“无新”警报,那么您可以在 Sonar 中设置的错误阈值有什么用?
    • 另一个想法。例如,假设我们定义不能添加新的严重违规。因此,我们在构建服务器上的构建将是红色的。假设运行了一个新构建并且没有添加新的违规行为。尽管失败的违规行为仍然存在,那么构建是否会变成绿色? 1. 我们有 10 项严重违规。 2. 添加了一个严重违规,因此构建失败。 3.第11次严重违规未修复。 4. 再次检查代码,没有添加新的违规行为。 5. 构建的结果是什么?
    • 测试过了。第二次构建将通过,因为没有添加新的违规行为。那么解决方案是什么。
    • 评论 #1:在处理差异警报时,我通常只使用错误阈值。
    • 评论 #2 和 #3:这是因为您已将差异周期设置为“自上次分析以来”。您应该将阈值设置为“自特定日期以来”或“自特定版本以来”。这样,您将始终与相同的基准进行比较,这意味着您将能够检查自开始应用这些要求之日起是否引入了新的阻止程序问题。见docs.codehaus.org/display/SONAR/…。以防万一您还没有使用它,另请参阅docs.codehaus.org/display/SONAR/Build+Breaker+Plugin
    猜你喜欢
    • 1970-01-01
    • 2014-08-24
    • 2012-02-16
    • 2016-01-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-06-11
    • 2019-07-13
    相关资源
    最近更新 更多