We are using SonarQube Enterprise Edition Version 8.6.1 (build 40680) to analyse a java project.
We have feature branches merging to long-lived team branches, that merge to a main branch.
The PR analysis seems to be fine.
We have configured the new code analysis for the team branches to reference the main branch.
We are using Jenkins to trigger the analysis, but the pipeline starts the analysis from a base box and the repository is cloned for the first time each time (so can’t see how we’re running in to the Jenkins/Git short-cut issues mentioned on a few other posts).
When we have reverted code (using git revert ) we are not expecting to see any issues flagged for code that is now back as it was on the main branch. We are however seeing “new code” issues for files that are effectively unchanged.
One of the other posts says you are using Git to figure out the changes, and that you are using “git merge-base HEAD mainline” to identify the common parent commit. We are still in the analysis stage at the moment, but would like to loosely know how the list of changes is derived to look at from this commit as we cannot see how some of the issues are being flagged when they are clearly not changed code, and the methods are not seeming used or affected by the changed code.