Using Sonarqube 10.3
I will try to describe what we want to achieve and why currently this seems to be impossible with the latest releases of sonarqube. before PR analysis got broken by optimizing it.
Goal1: No PR is allowed to introduce NEW issues to the master
Goal2: A release from master is not allowed to have any issues in overall code.
Having the new quality gates in theory it makes perfectly sense to only look for issues on new code, BUT Sonarqube does not catch everything here because of limited PR analysis. So even if NewCode is clean we introduce several times a month new overall issues to master.
Having overall code issues = 0 is also bad, because every activation of new rules otherwise blocks all PRs by possibly introducing new issues on master.
Having not the option to define different quality gates for long living branches I have no chance to fail the release deploy when there are overall sonar issues.
Kind regards,
Michael
Hello Michael,
Thank you for the feedback. It is true that the PR scan will not detect all issues and the branch (main in your case) is essential to keep your new code clean.
To keep the overall code clean, you will need two things from my perspective:
-
A Clean as You Code ready quality gate with a new code definition that is suitable for the team’s context. This will allow the team to make sure that there is no new issue on your main branch in the new code period.
-
You will still need a solution to address newly detected (due to analyzer improvements/enabling of new rules) issues on the main branch. You will need to set up conditions on the overall code to cover this case.
Will you help me understand your situation better:
What is your New Code Definition (NCD) for your long living branches?
When a new rule is enabled in the quality profile, do you want those issues to be fixed only in the new code?
Hi,
this means you recommend to use a combination of conditions on new code and on overall code ?
Gilbert
1 Like
Hi Vivek,
what you recommend is true but not doable with sonarqube currently. And thats my point.Mixing conditions on new code and overall code is bad for pull request workflow, but I’m not able to define different quality gates for long living branches
Kind regards,
Michael
Hello Gilbert,
Sorry for the late reply.
Yes. If you need to enforce specific quality criteria on overall code (alongside Clean as You Code), currently using additional conditions on overall code is the usable solution.
Do you have any thoughts on how you would like SonarQube to facilitate this user goal?
Hi Michael,
Conditions on overall code have no effect on Pull Request workflow or Pull Request quality gate status. Only conditions on new code are applied.
To further clarify on your goals:
Goal1: No PR is allowed to introduce NEW issues to the master
We prioritize scan speed in PR scans to give quick feedback to the user. Currently, SonarQube cannot report some issues in the PR scan. So, a branch scan (of the master branch) is required after the merge to ensure clean code on the master.
We understand that discovering new issues on the master after merging is inconvenient. To address this, we are evaluating possible improvements to PR scan.
Goal2: A release from the master is not allowed to have any issues in the overall code.
When a new rule is activated, and this rule violation is present in the change list of a PR, it will fail the PR quality gate. However, if the rule violation is outside the change list (and is in old code) this should not fail the PR quality gate. However, if you have a zero issues condition on the overall code, the main branch quality gate will fail. This is in line with your expectations as per my understanding.
Having overall code issues = 0 is also bad, because every activation of new rules otherwise blocks all PRs by possibly introducing new issues on master.
Please help me understand how PRs are blocked.
Hi,
IMO the clean code approach has to differ between legacy and new projects.
At least it should be mentioned in the docs and on the quality gate dashboard.
I don’t think everyone realizes that the current clean code approach - with only conditions on new code - runs the risk of introducing - potentially critical - issues during the initial scan of a new project.
Gilbert
1 Like
Hi Vivek,
so as PR scan on new code does not prevent 100% to introduce new issues after merging, the only solution currently would be to activate also 0 issues for overall code.
Having this in PRs activated per se is fine, but we often enable additional rules or rules do find new stuff after sonarqube update. Then your overall code on master has issues due to new rules activated or the sonarqube update and then all PRs are blocked because of the quality gate and can only be merged if someone fixes issues on master which they did not introduce.
Therefore having issues on master would be fine for us, but then I would need a quality gate for our release branches that really enforces 0 issues on overall code. So someone has to fix the master issues before the release. But Quality Gates are not branch specific and I can also not choose them when starting sonarqube analysis.
So your decision to fasten PR sonar checks does blow up the whole concept of quality gates in our case.
Kind regards,
Michael
It is true that the PR scan is not able to report all issues as of now, and we are trying to improve this behavior.
Until then, 0 issues condition on new code should cover your use case of ensuring clean new code on any given branch. For example, if you are using the reference branch as a new code definition, all the code changed compared to the reference branch is compared to new. Thus new code conditions are applied.
However, activating new rules in the quality profile or SonarQube upgrades can result in ‘newly detected issues’ in old code. The Clean as You COde methodology could not have helped in this case as the defined quality standard (clean code goal) was different at the time this code was written.
Do I miss something?