After upgrading from 7.9 LTS to 8.9 LTS, we have noticed some cases where a branch “feature” is created right on “develop” (with no additional code) and and an analysis on this branch contains a few bugs and smells when it should contains 0 bug and 0 smell.
The use of sonar.branch.target worked for this in 7.9 LTS.
UPDATE : This may be about the last commit of “develop” wrongly included by sonarqube in the new feature branch (maybe a locale problem ? we are in Paris UTC+1 here).
Hi,
Can you see if this is relevant, please?
Ann
Hi Ann,
Thank you for your suggestions.
it’s not directly related since for our test, our new branch is just empty (no merge no rebase).
But it would be interesting to know which git commands are used to evaluate the “merge base” in : “it finds the merge base and assumes that any line modified after the merge-base is new (by comparing commit dates)”. This way we can simulate manually what the scanner does.
Also if a “major bug” is fixed, it will be available for 8.9 LTS right ? not only for 9.3 like it’s said in [SONAR-14929] New Code using a 'reference branch' doesn't detect changed code with git merge workflow - SonarSource ?
Hi @Tristan107,
I am afraid more information will be needed to reproduce it on our end.
Can you confirm that before running an analysis on “feature” branch you always run analysis on “develop” branch?
Is there any chance that you could share the log of the analysis?
Does it happen only for “old” projects or are you able also to reproduce this issue on fresh SonarQube project with just one reference branch and one “feature” branch?
Thank you
Hi, here are some answers :
Can you confirm that before running an analysis on “feature” branch you always run
analysis on “develop” branch?
No, only feature branche are analyzed and then merged to develop. According the
definition of “New code” using “reference branch” this shouldn’t be a problem, is it ?
Is there any chance that you could share the log of the analysis ?
We have the logs and we can share relevant parts of u can delimit them, but we can’t publish the full content of these logs.
Does it happen only for “old” projects or are you able also to reproduce this issue on
fresh SonarQube project with just one reference branch and one “feature” branch?
By “fresh” project, you mean just one analysis on the feature branch with no previous analysis right ?
According the
definition of “New code” using “reference branch” this shouldn’t be a problem, is it ?
Ideally, yes, it shouldn’t be but because of some bugs linked above by @ganncamp in some exceptional cases it may happen that this feature works more reliably if you scan your base (so in your case “develop”) branch when branching (creating new “feature” branch). Could you try it?
The use of sonar.branch.target worked for this in 7.9 LTS.
The support for this parameter has been dropped in 8.1 as you can see in the upgrade notes. Could you use sonar.branch.name instead?
By “fresh” project, you mean just one analysis on the feature branch with no previous analysis right ?
Yes.
Hi, I’ve tried to reproduce what you may do to find the “fork point” and his date.
If I checkout my “feature” branch, and I do :
git merge-base --fork-point develop
It doesn’t give any commit as result.
If I do :
git merge-base develop feature/test-sonar-new-code
It gives me the right fork point. On this fork point I can extract the date and take it as reference :
git show -s --format=%ci 123456789eec
2022-01-06 14:03:55 +0100
Is there a chance you use “–fork-point” which is known to work incorrectly ?
We have also tried your suggestion analyzing the develop branch before creating a feature branch, but it doesnt change the result.
It would be really useful to share the git commands you are using to find the reference date to reproduce the bug on our tree. Are they different from what I suggest ?