Issue creation on pull request


(Mattmoskwa) #1

Can I get clarity on when issues are created from pull requests? The documentation says

The issues visible on the short-lived branch are the new issues corresponding to files modified in the branch.

Modified files are determined based on the checksum of each file on the sonar.branch.target and the short-lived branch.

This appears to indicate that any file modified in that pull request will be fully scanned for issues and those issues will be reported as part of the PR, even if those issues are from lines that were not modified in the PR. This seems to be what is happening in our case. Is there a way to change that behavior so that issues are only created if they are caused by the new code?


(Julien Henry) #3

Hi @mattmoskwa

Today, there is almost no optimization during scanner side analysis. The entire project will be scanned. This is to avoid false negative regarding cross file issues (ie changing a file/line can create an issue in another file/at another line), and also to have proper coverage and duplication report.

Then we retain only issues on added/changed files. This is both because our UI (and most ALM PR UI) would not allow to show them anyway, and also to avoid some false positive (see below).

Then “issue tracking” is made, to compare issues detected in the PR with issues detected in the reference branch (usually the target branch of the PR). After this step we know which issues are new.

The most common case of false positive is when the target branch is not up to date in SonarCloud (not yet analyzed, or analysis is too old) or when the branch of the PR is not rebased on the target branch.

For example if an issue was already fixed in the target branch, but you PR branch is not yet rebased on it, the analysis will think your changes are responsible for the issue and will report it in the PR.