8

We are using SonarQube 5.5 (latest to date).

Our project contains a lot of legacy code that wouldn't pass our desired Quality Gate, so we decided to ignore technical debt which is already there, but be strict about new changes.

So we are enjoying Leak concept and default Quality Gate that considers only new changes.

We use Continuous Integration and Continuous Delivery, so we run SonarQube analysis for every CI build to be able to give immediate feedback to developers whether their changes fail the Quality Gate, so issues are not left till the end of sprint, or new technical debt accumulated.

We set Leak Period to previous_version as we increment version number every run, but as far as I understand it could be set to previous_analysis in our case with the same effect.

The problem with this approach is that next good commit will clear the state of the project (Green, was Red) as analysis for last only commit will pass the Quality Gate. Although the code already contains the issue introduced in previous commit.

If Leak Period is set to a fixed date\version (A custom date or A version options), analysis will run for cumulative commits, and individual "bad" commits can squeeze through unnoticed, causing issues later in the cycle. So it doesn't satisfy "immediate" requirement. Imagine that after a fixed date\version there were 5 commits of the same size - 4 from "good" developers following TDD so with 100% coverage, and 1 from "bad" guy whose changes has 0% coverage. In average it will pass the default condition "Coverage on new code is not less than 80%", but in reality we want to give feedback to such "bad" guys as soon as possible, so they improve their practices.

If Leak Period is set to rolling Number of days before analysis, the state of the Gate will clear as soon as this number of days passes since the last "bad" commit, while issue could still be there in the code.

We need to be able to analyze individual commits (similar to "previous_version" Leak Period option in SQ). But in case last commit passes QG and previous one failed, we should analyze them together to see if last commit actually fixes the problem from previous one, so that the project as a whole can be deemed as passed.

So, in essence we should be analyzing all the commits since the last successful analysis

There is no such option for Leak Period. Is there any other way to achieve this?

Ivan
  • 9,089
  • 4
  • 61
  • 74
  • I don't understand why the "A version" or "A date" wouldn't work. At SonarSource, we are running analyses on each commit, and leak is set to "previous_version" (because we don't increment the version on each commit): that works perfectly. You can't miss issues introduced in a bad commit that happened during the leak period (whatever the period) because issues are tracked. So I don't really understand your problem. – Fabrice - SonarSource Team May 10 '16 at 20:08
  • @Fabrice-SonarSourceTeam, sorry for not explaining this better. Imagine that after a fixed date\version there were 5 commits of the same size - 4 from "good" developers following TDD so with 100% coverage, and 1 from "bad" guy whose changes has 0% coverage. In average it will pass the default condition "Coverage on new code is not less than 80%", but in reality we want to give feedback to such "bad" guys as soon as possible, so they improve their practices. – Ivan May 11 '16 at 10:08
  • @Fabrice-SonarSourceTeam, also, IMHO logically if code passes Quality Gate in SonarQube, it could be deemed as "good" and so Leak period can be reset to this version of the code. In your case if I understood correctly you increment version manually only when you are happy about that version not just from SonarQube perspective but after some other checks (completeness of the version?, tests passing in the pipeline?, etc), so only then you increment the version and it resets the Leak Period. But ... why analyzing code which has already been analyzed earlier and deemed to be "good"? – Ivan May 11 '16 at 11:08
  • @Ivan you'd be better served by code reviews to help a developer improve his code coverage – Teryk - SonarSource May 11 '16 at 12:24
  • @Teryk-SonarSourceTeam, thanks for suggestion. We already do code reviews. However whereever we can, we try to automate quality checks, to spare time of senior devs\architects. Is it not in line with SonarQube purpose? – Ivan May 12 '16 at 13:11
  • @Ivan absolutely! The real question is how to track individual code coverage, right? You could use the rules [InsufficientLineCoverage](https://nemo.sonarqube.org/coding_rules#rule_key=common-java%3AInsufficientLineCoverage) and [InsufficientBranchCoverage](https://nemo.sonarqube.org/coding_rules#rule_key=common-java%3AInsufficientBranchCoverage) to help you – Teryk - SonarSource May 12 '16 at 15:23
  • @Teryk-SonarSourceTeam, thank you, I'll have a look. We use C# but I can see the same rules for C# too. – Ivan May 12 '16 at 16:14
  • @Ivan how you solved? I'm in the same your use case – Luigi Saggese Jan 09 '19 at 09:54
  • 1
    Unfortunately never solved this. – Ivan Jan 11 '19 at 09:25

1 Answers1

-1

To track a developer's code coverage you can do several things:

Teryk - SonarSource
  • 994
  • 5
  • 12
  • So, using these 2 rules how exactly can I configure to check that 80% of the code is covered since last successful analysis? – Ivan Jun 04 '16 at 09:19
  • 2
    Sorry, but I can't agree with suggested change in title. I don't want to track developer's code coverage. I want to get an early feedback about any commit (no matter from which developer) failing Quality Gate. In line with Agile and Continuous Delivery specifically. I wish you guys at SonarQube really understood this concept, instead of "bending" community to what you already have. e.g look at logics in comparing against "last successful build" in TeamCity failure conditions: https://confluence.jetbrains.com/display/TCD9/Build+Failure+Conditions#BuildFailureConditions-Failbuildonmetricchange – Ivan Jun 04 '16 at 09:33
  • To get an early feedback about any commit, launch an analysis at every commit. That's what we do. About Continuous Delivery, the Quality Gate check is part of our release life cycle. Set InsufficientLineCoverage rule with an 80% coverage to create an issue. Be aware it will create an issue on every file that have less than 80% of code coverage. HTH – Teryk - SonarSource Jun 07 '16 at 12:39
  • you might be interested by the [Build Breaker Plugin](https://github.com/SonarQubeCommunity/sonar-build-breaker). Here's our [stance](http://www.sonarqube.org/why-you-shouldnt-use-build-breaker/) – Teryk - SonarSource Jun 07 '16 at 12:43
  • Link only answer has basically expired. –  Mar 07 '17 at 21:18