We'll apply to all branches the "light issue tracking" we've experimented with
SONAR-11859: We'll consider issues to be "new" if they have at least one location on the lines touched in the branch. The same criteria will be used to calculate "new measures" related to issues.
Currently, pull requests need to target another branch. The target branch might not exist in SonarQube (if it wasn't analyzed).
The target branch can also be a PR, which means it won't have (in SonarQube) the full information about all files in the branch since we only stored changed files for those types of branches. In that case, we need to find a LLB that can be used as a reference for the analysis (to load settings, potentially compare changed files if there is no SCM, etc). If the target is a PR, we find a LLB by transitively getting the target until we reach to a LLB (if there is a loop, the analysis fails).
For example, if a project in SQ has two branches:
- L1, which is a LLB
- S1, which is a PR that targets L1
And we submit an analysis of the branch S2 targeting S1 and an SCM is available, the following information will be sent from the scanner to the compute engine:
- "Target branch" is S1
- "Merge branch" is L1
- Changed files and changed lines in the HEAD of S1 using as reference the latest fork point between S1 and S2 (we use the git SCM plugin in the scanner to fetch this information from git).
We can see this has a hierarchy of branches: L1 -> S1 -> S2.
In the CE we take the following steps:
1) If there is a "merge branch" (the first LLB going up in the hierarchy)
=> Compare issues found in the analysis with issues the "merge branch"
2) if there is a "target branch" and it's not the same branch as same branch as the "merge branch"
=> Compare unmatched issues (the ones that didn't match in 1) with issues in the "target branch"
3) If there is no "merge branch" and no "target branch"
=> Keep issues that have at least one location in a changed line.
4) track issues with issues of the previous analysis of the same branch, to keep any existing information about them.
To simplify this, we will drop steps 1) and 2).
For reference, see org.sonar.ce.task.projectanalysis.issue.ShortBranchOrPullRequestTrackerExecution