New issues are automatically assigned during analysis to the last committer on the issue line if the committer can be correlated to a SonarQube user.
Why are existing issues not automatically assigned to last committer on the issue line during analysis after they are fixed in the source code?
The automatical assignee of a new issue is not necessarily the real fixer.
For an issue whose state was closed after analysis, there is now no way to see who fixed it on the issue.
Hi,
This is a great question, and in theory one way to give credit for fixing issues.
Unfortunately, it’s more difficult in practice than it might seem. Why?
Well, with each analysis, a set of issues is reported on the code. The docs describe how we figure out which issues are new and which are existing issues that are being re-reported, i.e. that are still in the code. The issues that are Closed are the ones that were open in the previous analysis but that aren’t in this newest report.
For a new issue, it’s easy enough to attribute it to the last committer on the issue line. For a closed issue… well there are multiple ways to fix an issue. You can address it on the line (so last committer would work); you can address the pre-conditions that lead to the issue; you can delete the problem; you can… do other things. And in most of those cases, identifying the fix line would be problematic, especially if some other change in the commit shifted the line the issue was on up or down in the file.
So… that’s why we don’t do this. Instead, we simply mark the issue Closed and delete the line number from it - because it’s actually pretty common that the old location of the issue shifted at some point and leaving closed issues attached to their old line numbers (i.e. to code that’s often no longer relevant to the issue that was raised) is confusing.
Does that make sense?
Ann
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.