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?
