We have recently bought the Developer Edition of SonarQube 7.9 LTS to replace our previous analysis method using the issues mode. After reading the documentation and fiddling around a little, I’m at a dead end and would like some input on my approach.
Our situation is this: we use the Git-Flow branching model and review every commit using Gerrit Code Review. For feature development, developers start a feature branch, add some commits over time and finally merge it back to develop, the main branch. A second developer will review each commit that gets pushed to the server and makes the final decision on whether the code is allowed to be released to the main branch. Each commit is built by Jenkins and detected SonarQube violations are added as comments to the Gerrit change (roughly equivalent to pull requests on GitHub etc.). This relieves the reviewer from repetitive tasks like finding obvious programming issues and allows them to focus more on the functionality itself.
Up to now, we ran a Jenkins build for each commit and read the locally generated issues from the scanner. The issues then were sent as comments to the Gerrit change when two conditions applied: the issue was new in respect to the current state of the main branch (we didn’t have branch analysis then) and violations were only commented when the line was modified in the commit.
This approach had two issues:
- Violations that appeared due to a change but not on a changed line (think of removing the use of a method parameter but not changing the signature) were not commented and therefore ignored
- Any new issues were always based on the current main branch’s state and not on the state of the actually worked on branch, which caused that we couldn’t manage violations (mark them as resolved, won’t fix, etc.) on the SonarQube server, because this would affect the analysis of any currently open branch
With the branch analysis support of the Developer Edition, we can finally manage violations by branch, but I don’t see how we can effectively only comment issues on changes that were the root cause of those issues. Imagine the following situation: a developer prepares two commits, one adds basic functionality, the second adds advanced functionality to the same files. Another commit will be the merge commit to the main branch, which in our current scenario will not only be analyzed by SonarQube but also executes tests to calculate coverage and the quality gate.
The developer raises a violation in the first commit without noticing and later submits both commits for review. Now, SonarQube would flag the violation created in the first commit in both commits, because in comparison to the current branch state (both commits are still in review and therefore not publicly visible on origin) both commits contain this new violation. However, the developer only has to fix the violation in the first commit, because the fix then automatically propagates to the second one that depends on it.
How would I model such a workflow in SonarQube with the branching capabilities?
When I create both commits as a pull request, SonarQube doesn’t seem to notice that the second pull request depends on the first one and therefore cannot be merged without it, which means that any flagged violations are cumulative.
When I make a branch analysis for every one of those commits, the violations on the branch will fluctuate wildly, because multiple developers can have different commit chains in review for the same branch. This would also again prevent us from managing issues on SonarQube, because the issues privately solved (not already pushed) by one developer can still be contained in the changes of another one.
Any input on this matter will be greatly appreciated. I don’t think that SonarQube currently has the use case of reviewing each commit in mind.