We have an integration with Azure DevOps using Pull Request decoration. We were wondering if there was any way where instead of comments being deleted, the comments could be marked as closed/resolved/won’t fix or otherwise not deleted?
Could you share your SonarQube version and why you prefer resolution to deletion?
We are on SonarQube 9.9 LTS. The reason we want to keep the comments with SonarQube pull requests is the same we would want to keep the comments for any other PR. The current and historic data are valuable for both developers and leaders. The automated comments are just as valuable as a human leaving a comment, so we would like to be able to still:
- have a conversation to assist developers if they questions in properly addressing the changes required
- review the comment to make sure the rules meet our coding standards and aren’t a false-positive, and record in the PR any conversation to that effect
- use any conversation as a training or evaluation document for future needs, or to help us remember any decisions that were made in the past
Thanks for this insight. I think our approach to this has been to delete the comments for fixed issues in order not to intrude on the human conversation.
I’ve moved this thread to Product Manager for a Day, since you’re asking for a change, and I’ll flag it for the attention of the (full time) Product Managers.
Thank you for your insight on this.
Indeed when issues are solved the comments will be deleted on Azure DevOps. Nevertheless, when you change the status on SonarQube as won’t fix/false positive it will be replicated in the comments.
I don’t know if you are aware but all the solved issues can be found on SonarQube, I’m wondering why don’t you use it to track the information?
The issue is that our developers rarely log into SonarQube itself. Our ALM toolset is Azure DevOps. We don’t want to have to have our developers switching between tools unless it’s necessary, and having to go to multiple sources for historic data is inefficient.
Thank you for the quick answer.
I understand that switching between tools can be inefficient at some point.
We have made the choice to delete the comments when the issues are solved to be aligned with the current codebase. Otherwise, you would see comments linked to issues that don’t exist in the code anymore, does it make sense?
I have another question:
Why do you want to review comments on solved issues that are not on the codebase anymore?
We are also experiencing this issue and it is a major issue to be honest.
You ask “Why do you want to review comments on solved issues that are not on the codebase anymore?” - I will answer that!
Its very common for PRs to be in place for a few days at least and have to be reviewed by many different people. When the PR request is created, Sonar might highlight 10 issues for example. Some of those issues may be fixed and PR branch might be updated, while other issues might be by design, or won fix, where comments will be added explaining why.
So then someone wants to review the PR, but the 10 issues that were resolved through various reasons are no longer there to be seen in the PR. There are orphaned comments there, sometimes explaining why the fix wont be made or by design but the original Sonar issue comment is gone.
It makes no sense to have these Sonar comments removed, doing so makes the usage of Sonar with Azure DevOps very cumbersome indeed.
Can this behaviour be changed, can the Sonar comments in Azure DevOps remain or at least have the option to configure not to be deleted, even if resolved?
First of all, welcome to our community!
Thank you for the explanation provided regarding this topic, we really appreciate you took the time to share it. In this case, we don’t have any plans to address this on our current roadmap, but if we find evidence that it’s a wider problem we’ll look into it further.