I’ve looked all over the SonarCloud documentation and in the Sonar Community, but have not found any references in the context of SonarCloud. What I found was an old thread related to SonarQube:
So it would seem, that SonarCloud is way behind SonarQube in the regard of allowing us to indicate, that a specific branch (long-living one in our case) is based on a different branch and that only the differences in comparison to that “base” branch should be considered as New Code.
Is there anything on when this feature will be available in SonarCloud?
In regard to my searches through the SonarCloud documentation:
The documentation for SonarCloud seems to indicate, that “sonar.branch.target” only affects new code detection for short-lived branches and only affects issue synchronization for long-lived branches. The “sonar.newCode.referenceBranch” is not mentioned in the SonarCloud documentation.
For someone forced to use SonarCloud (by company policy) in an enterprise setting (similar to those described in the linked topic, i.e., projects with multiple branches, reflecting multiple versions and/or variants of the same product, all with active support and thus needing a way for maintenance versions to be properly tracked and analysed against correct reference points), this is a huge issue.
Thank you hilari0n for starting that thread. I was looking for exactly the same thing:
A possibility to specify the reference branch (for both short- and long-lived branches) on SonarCloud (in opposite to SonarQube, which has sonar.newCode.referenceBranch).
Two points to add:
An ugly workaround is to run the analysis on the branch with pull request parameters, as described on the Analysis Parameters page. Btw., the description for sonar.pullrequest.base is wrong (copy/pasted from sonar.pullrequest.key).
I’m eagerly waiting for more response here!
Thanks!
From some tests, my colleagues have made, it’s not that sonar.branch.target does not work at all. It seems to be considered for “New Code” recognition for short-lived branches and for issue synchronization (for both branch types).
The workaround we’ve decided to use for long-lived branches, is to use the “Previous version” setting for “New code” in the project, then make sure, that the first scan for a certain branch is actually made for the base branch state of it and only the subsequent scans to be of the actual branch state and then manipulate the version numbers in such way, that the initial scan (so of the base branch state) is considered the previous version for this branch.
This is a crude hack, very tedious and error prone. Also for some of our repositories, this seems to cause a different issue to surface: the issue of new code not being detected (forcing us to use sonar.scm.disabled=true):
Thanks for sharing your experience. Are you sure sonar.branch.target had an effect on short-living branches? It wasn’t the case for me, and it’s also not mentioned in the Analysis parameters page.
Anyway, now I understand that your request here has a slightly different aim, I will create a new post for my specific issue.
As far, as I remember my colleagues’ explanations, it seems to be working (for the “New Code” specification), if you have a scan for a short-lived branch, which references (with sonar.branch.target) a long-lived branch.