SonarQube Server automatically assigns an issue during analysis to the last committer on the issue line - called issue author - if the author can be correlated to a SonarQube Server user. Otherwise, it assigns the default assignee if a default assignee is configured in SonarQube Server.
We cannot rely on this mechanism because the last committer is meaningless in our monorepo: it has been developed by multiples teams over many years and file modification does not mean ownership.
Assignment must therefore be handled by us programmatically using the Sonar API and it takes several hours for >300k issues.
We assign code ownership on "modules“, a logical collection of folders and files spread across the monorepo, and to teams instead of individuals.
To achieve this we are using a flat CODEOWNERS like file that contains a mapping of every single file in our monorepo to its team owner, one per line:
The current size of this ownership file for our monorepo is ~90MB.
Considering we already have this ownership mapping when running the Sonar scanner, I would like to know if it would be possible to have a property to submit this file and have Sonar assign issues based on its content:
Only the latest version of SonarQube Community Build is considered active, so you’ll need to update and see if the situation is still replicable before we can help you.
If you have questions about upgrading, feel free to open a new thread for that here.
Regarding your question, it sounds like you’re re-assigning all >300k issues each time? Why would you need to do that? Surely the code ownership doesn’t change that frequently? You should be able to get just the new issues and adjust their assignments.
You are correct that we are not re-assigning all our current >300k issues each time.
However, we are regularly enabling/disabling rules for assessment that can end up creating 100k+ issues and we have the same post-processing slowness here.
Would you mind sharing why? To be honest, SonarQube just wasn’t built for that. I mean, sure. Test the rules out and turn back off the ones that don’t make sense for you. But to churn through so many rules so many times that you’re assigning hundreds of thousands of new issues on a regular enough basis that performance is a concern? No.
The performance of the Sonar background analysis is not an issue.
The issue is that the only assignment way we have is through the Sonar API and it’s a bottleneck starting any “big“ number of issues.
We do it because Sonar is our quality dashboard, it allows us to estimate the cleanup work and the impact of a rule for teams / modules in our organization.