We use SonarQube for static code analysis of a Java project. Auto-assignment of new issues mostly works, but quite often new issues end up unassigned. We’d like to understand why and how to make it reliable.
Environment
SonarQube version: [e.g. v25.6.0.109173 Community Edition]
Scanner: Jenkins plugin
SCM: Git, analysis runs on Jenkins
What we observe
a new issue is left unassigned although the line’s author has a SonarQube account
What we have checked so far
Jenkins checkout: full clone
Questions
How exactly does SonarQube choose the assignee for a new issue? Is it always the author of the most recent change on the issue’s line(s), or the author of the commit that actually introduced the problem?
What happens when an issue appears on unchanged code, e.g. after a quality profile/rule change or a change in another file? Does it go to the last person who touched that line, even if they had nothing to do with the new issue?
Do merge commits or squash/rebase workflows affect which author blame reports?
Are there known setups (shallow clones, CI workspaces, detached HEAD, etc.) that make blame data incomplete and cause issues to fall back to unassigned or the default assignee?
Is there any logging or API endpoint that shows why a specific issue was assigned the way it was?
Any hints or best practices would be much appreciated. Thanks!
Let me start by just stating the most plausible theories for what you’re seeing:
SCM data wasn’t accessible by the Scanner at the time the issue was first raised.
The SCM login name associated with an issue is longer than 255 characters (including the characters for an issue author), which causes the author to be left blank.
Point 1 is based on how automatic issue assignment works in general (more detail below), point 2 is based on a documented, known limitation (see the info box here).
How exactly does SonarQube choose the assignee for a new issue? Is it always the author of the most recent change on the issue’s line(s), or the author of the commit that actually introduced the problem?
SonarQube assigns a new issue to the last committer on the issue line if that SCM identity can be matched to a SonarQube user (login, email, or SCM account); otherwise it uses the default assignee (if configured) or leaves the issue unassigned, and this happens only when the issue is first created.
What happens when an issue appears on unchanged code, e.g. after a quality profile/rule change or a change in another file? Does it go to the last person who touched that line, even if they had nothing to do with the new issue?
Yes. The issue might be backdated, but even with that, assignment will be done based on the last known committer.
Do merge commits or squash/rebase workflows affect which author blame reports?
Yes, indirectly. SonarQube just uses SCM blame, so any history rewrite (merge style, squash, rebase, repo migration, etc.) that changes which commit is last on a line will change the reported author.
Are there known setups (shallow clones, CI workspaces, detached HEAD, etc.) that make blame data incomplete and cause issues to fall back to unassigned or the default assignee?
Yes, if SonarQube doesn’t have blame data for that line for whatever reason, issues detected there won’t have an author. The scanner logs typically contain warnings when this happens.
Is there any logging or API endpoint that shows why a specific issue was assigned the way it was?
Not really. What you could do is, look for the particular analysis where the issue was introduced (you can find the creation date of an issue in the UI and then correlate it with your CI scanner runs) and check if there are warnings in those scanner logs complaining of missing SCM data for that file. This could let you know if at the time the issue was introduced, SCM data was missing, which is the most plausible explanation for the behavior you’re seeing.