which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
Developer Edition Version 9.9.1 (build 69595)
how is SonarQube deployed: zip, Docker, Helm:
As a big fat linux service.
what are you trying to achieve:
We have multiple repositories with master, develop and feature branches.
When security hotspot are found on a feature branch, we review it and add an exception (or not depending the case).
Later on we merge the feature branch into develop.
After that when new branch is created from develop the code exception does seem to be taken into account
what have you tried so far to achieve this
We also tried to merge develop into master thinking the comparison was done compared to master but still have the same behavior.
Are the exceptions propagated from feature branch to develop? or master? Does the branch name affect the propagation? Do you have recommendation on how we could deal with this problem to avoid to have to add exception for every new branch? Any hint would be appreciated…
Thanks for your reply.
Just to be sure, when you write “PR”, you mean Push/Pull Request?
We merge from feature branch to “develop” branch; later on we spawn a release branch from “develop” and that release branch gets merged to “master” (main). We use sonar-scanner 4.8.0.2856 to launch the analysis but I am not sure if / how the exception is then propagated?
I suspect not: In our CI/CD we bluntly use the sonar-scanner cli to check the code; if the sonar-scanner command returns an error, we mark the build as “failed”. In general we go back the the sonar web gui to add an exception re run the scanner and if ok merge with git.
Do you mean we should setup pull requests in sonarqube instance? Is there a guideline on how to do this?
Issue status is simply not synched from branch to branch except from main to a feature branch at branch creation.
If you want issue status syncing back into main, then you’ll need to (re-)mark the issues in PRs. That said, since you’ve already marked the issues in the feature branch, it’ll be re-work to re-mark them in the PR. It may be easier to just keep re-marking them in main once they arrive.
The docs should get you started on PR analysis if you still want to go that way.
Sorry to re-open the topic, but in the response above:
Assuming we setup the PR correctly and added at least once the exception on a feature branch that is directly merged to main; will any derivative branches have the exception (including the derivative of a derivative of main?) or only the feature branches deriving directly from main?
Thanks for the quick response.
When I wrote “added at least once the exception on a feature branch” I meant that we have a PR and we mark the exception in the GUI of sonarqube server (IE we get a security hotspot but we mark it “safe”).
I did the exercice today:
did a modification from master
create a PR
we get a security hotspot (false positive in my case)
we mark it safe
merged the PR into master (our “main” is called “master”, not sure if that could impact here?)
merge master to develop
created a feature branch from develop
commit and push new code to the feature branch
==> Sonarqube flags the same security hotspot; I understnad this is it expected? But if we were to merge develop back to master via a PR, the security hotspot would not be flagged anymore?
In the UI for the PR you marked it ‘safe’ in the PR, right?
==> Yes
And in main it was marked ‘safe’, right?
==> I assume yes: When the PR (branching off master) is merged back to master we do not retrigger a sonar scanner on the master (should we?). The master is marked green in the branches list visible on sonarqube server:
Okay… which branch does SonarQube treat as your main branch? I.e. which branch do you see when you first go to the project in SonarQube?
==> “master”, we more or less follow the standard gitflow with feature branches Gitflow Workflow | Atlassian Git Tutorial; the sonarqube analysis runs on every feature branch at the moment (If I understand correctly, that is probably not how we should do it?)
Yes. It’s possible for changes in a PR to raise new issues in old code. Those new/old issues won’t be reflected in the PR. (Yes, we know that’s not ideal.)
And… we’ve discovered the cause of the mystery.
You merge an accepted/Safe Security Hotspot into main
You don’t analyze main - so the Security Hotspot doesn’t exist in main, therefore it’s not accepted/Safe in main
You create a new feature branch (essentially) from main and analyze it => new, unaccepted/unSafe Security Hotspot in the feature branch because the Safe status didn’t exist in main to be propagated
