Must-share information (formatted with Markdown):
- SonarQube for Bitbucket
- Branch statistics and analytics
- Attempting to troubleshoot issue to confirm if this is a known bug, feature of plugin, etc
Noted issues:
Branch statistics displays wrong information about maintainability.
- according to the quality date, maintainability on new code C > A - that’s correct, I’ve introduced some issues
- according to branch statistics, maintainability is A
The only explanation I can think of is that for branch statistic maintainability is calculated as new issues/code on the whole branch. But why would such a metric make sense? Either I care about new issues/new code in my pull request analysis or all issues/all code in branch analysis. This is very confusing for the user.
When using the branch-based analysis mode, the size of the PR is calculated by the number of lines in the modified files.
When using the leak-period analysis mode, the size of the PR is calculated as the number of modified lines, as expected. Compare:
Coverage is calculated correctly on new code only using the leak-period analysis mode:
Merging one PR may affect data statistic of another one (probably when they both modify the same file):
Granted, I can display warnings when the source branch is behind target branch. But why would I need to do so? Sonar is intelligent enough to figure out which issues have been introduced by me, even if I don’t have the newest commit from the target branch on my branch. The plugin has access to this data. So forcing the user to run the Sonar analysis on the PR every time there is a merge to the target branch just to have the plugin perform the expected function doesn’t make any sense and isn’t user friendly.