we are facing an issue where the feature branch cloned from master is getting passed with sonarqube, but the master branch throws error(code smell and condition coverage) after merging the feature branch to the master.
The way the sonar analysis run is the same for both feature branch and master,
The new code period is set as reference branch to the master, where as the master branch is set to 30 days period.
Note we recently upgraded our sonarqube version to 8.9 LTS,
There are two questions here,
How is the reference branch new code period works, i believe it should be from the point of forking of the feature branch and gets compared to master branch. But every-time I do a rebuild of feature branch the new code period in sonar gets changed , is this expected?
what is the optimal setting for a new code period setting with reference branch?
Before focusing too much on the New Code Period, I think it’s worth that you check your Quality Gate to ensure that you are checking the same conditions on New Code as Overall Code.
Can you share a screenshot of the Quality Gate applied to this project?
Thanks. Normally issues like this arise when the New Code conditions are less strict than Overall Code, but clearly that’s not the case here
Maybe you can share a screenshot of a Pull Request that you expected to fail the Quality Gate but didn’t (and then those code changes failed the Quality Gate once merged into master). Is the Pull Request analysis actually reporting that anything has changed in the Code tab?
Apologies for the long delay the way we do the analysis, is that every feature branch gets sonar analysis run whenever a new code change is detected. It gets cleared of all issues reported and then merged into master branch, which again runs sonar analysis on overall code once again.
I dont have an pull request type analysis to share with you,
But recently found few issues
If i make 3 commits to my feature branches and run sonar analysis on the build where the 3rd commit is done, it picks up only the 3rd committed changes not the overall changes from reference branch.
Sometimes the files that are changed are held back from analysis with missing blame informations,
one such build snippet is below, where the newfilepath below is the file with newly added changes.
=====================================
build
15-Jun-2022 21:06:49
[INFO] This git repository references another local repository which is not well supported. SCM information might be missing for some files. You can avoid borrow objects from another local repository by not using --reference or --shared when cloning it.
build
15-Jun-2022 21:06:49
[INFO] SCM Publisher 2/4 source files have been analyzed (done)
build
15-Jun-2022 21:06:49
[WARNING] Missing blame information for the following files:
build
15-Jun-2022 21:06:49
[WARNING] * pom.xml
build
15-Jun-2022 21:06:49
[WARNING] * newfilepath
build
15-Jun-2022 21:06:49
[WARNING] This may lead to missing/broken features in SonarQube
This warning will only appear if .git/objects/info/alternates is found, which would indicate the repository is borrowing objects from another repository. I would double-check that your statement here is correct.
yes I am pretty sure. we use bamboo for our CI/CD process and we don’t have them enabled.
does this lack of blame information cause the new changes not being picked up for analysis, if so it shouldn’t be an warning.
we were able to fix the scm blame information by disabling the agent cache and it worked for us.
But still the problem of issues missing feature branch persists.
