Build-breaker plugin and incremental/preview analysis

514 views
Skip to first unread message

Louis Burton

unread,
Jul 13, 2015, 1:21:57 PM7/13/15
to sona...@googlegroups.com
Hi,

Are there plans to allow the build-breaker plugin to support incremental or preview runs?
We require them as we want to run through the sonar quality gates on transient feature branches before merging to our main branch, without a requirement to persist the results, but wanting the build to break on quality gateways (such as coverage). It seems limited if it's impossible to check if quality gateways have been violated until code has been merged and full analysis done, and prevents Sonar from being a good replacement for checkstyle/pmd/findbugs type plugins that can fail in the same way regardless of branch, and doesn't require persistence on each.

This seems to be a more recent change due to an altering of approach. I don't have a SONAR JIRA account and thus can't raise it as a bug there, however, I can find similar complaints in this area with no clear response on how this is being tracked.


Any response or indication of direction would be greatly appreciated as we're trying to steer whole heartedly towards Sonar usage.

Thanks,

Louis

Louis Burton

unread,
Jul 21, 2015, 7:00:25 AM7/21/15
to sona...@googlegroups.com
Is there anything else I can do to help get an idea of the stance on this, considering it's been asked separately by three others without conclusion also?

Fabrice Bellingard

unread,
Jul 23, 2015, 5:09:27 AM7/23/15
to Louis Burton, sona...@googlegroups.com
Hi Louis,

The Build-Breaker plugin will definitely be deprecated in SQ 5.2. So no plan on this plugin at all.

As I said in the different threads that you referenced, the idea is to implement native features in SQ to answer the use cases:
  • The main use case is the one you mentioned: checking the quality gate of an incoming set of changes before pushing it
    • In SQ 5.2, the preview mode should make it possible to give you the status of the quality gate if your analysis were to be submitted to the SQ server
    • Based on this, we can decide if the process that runs the analysis should fail or not
      • In a CI-like process, there are chances that you want the process to fail the analysis
      • In your IDE, you just want to display the information
  • The second use case is less frequent but still useful: you are doing automated releases and you want the release process to fail if the quality gate is not green
    • Such case will work in the same way as the previous one: we can make sure that the process fails to stop the release process


Best regards,

Fabrice BELLINGARD | SonarSource
SonarQube Platform Product Manager
http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/5e38c5c5-5e67-482e-a0cc-9a4893372d52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Louis Burton

unread,
Jul 23, 2015, 5:26:25 AM7/23/15
to SonarQube, fabrice.b...@sonarsource.com
Hi Fabrice,

Sorry I did not fully understand that from the other threads, and thanks for clarifying here, it is very helpful and good to know. Thanks for taking the time to reply.

We are doing both use cases you mention, and in the first, for the changes on a branch, we'd like the analysis to fail on quality gateways for incoming code without requiring to persist the results. The branch is for a pull request and the analysis being incremental would probably be sufficient. If it has to be preview, we can probably live with this. We would not want to persist full results for every incoming branch, which would be noisy and would accumulate in SQ.
Once merged, we do automate releases, and this would prompt a full analysis that is persisted and we would also want to fail on quality gateways.

I think the two scenarios you outlined meet what we're trying to achieve, and thus I look forward to these upcoming changes in SQ 5.2 and will push for further SQ integration.

Thanks,

Louis
Reply all
Reply to author
Forward
0 new messages