Can Github PR decoration be customized to include issue resolutions?

We’re running sonarqube enterprise 7.9.3. (Yes it’s on our radar to upgrade to the latest).
We have PR integration with github enabled.

Is there a way to see a summary of Resolutions performed in a PR?
In other words, if I don’t like an issue in my code on my pull request I can just go into the UI and mark it a false positive or won’t fix. When someone looks at the sonar check status on my pr, there’s no indication that I circumvented rules to get it to pass.

Is there a way to make resolutions show up in the PR decoration in github? Here’s a screenshot of a PR decoration in github where a security vulternability existed and was marked as false positive. You’d never know that as a pull request reviewer.

Hi,

Sorry, the only way to see this is to go to the PR’s Issues page in SonarQube and check the Resolution facet (collapsed by default):

 
:woman_shrugging:
Ann

Thanks Ann. I’ll take one last crack at this. Is that also true if I upgrade to the latest version? If so, is this integration somewhere public that I could explore extending / contributing to? Either way, is additional field visibility in the PR decoration something on the roadmap?

Hi,

My screenshot was from our internal dogfooding instance, so current+. Specifically, yes it’ll be true even after upgrade.

I don’t believe adding this is currently on anyone’s radar. I thought about creating a Feature Request ticket for it, but after some thought came to the conclusion that it would be futile.

Explicitly, given what I understand at the moment I don’t think it would ever be picked up to be implemented. Why? My current impression of this is that it’s about bureaucratic/managerial checking behind developers rather than empowering them and trusting them to do the right thing / a good job, which is really our raison d’etre.

If they’re not trustworthy/doing a good job, then that’s a different conversation. But really, the disposition of issues in a PR should be a conversation between the coder and the peer reviewer(s).

All that said, If you feel strongly about this, I encourage you to create a new thread in the New features category. There you can lay out your case for the feature (and correct my misunderstandings and bad assumptions) and gather support from other members of the community.

 
HTH,
Ann

Thanks Ann. I hadn’t considered a use case of a non engineer auditing via the PR decorations. I was only thinking it’d get used engineer to engineer during pull request review. The sonar UI provides enough auditing for those in security roles and I suppose managers; although I haven’t worked anywhere where managers get involved in code review. Displaying resolutions in github PR integration to me is to aid developers and architects during code review discussions and makes static analysis more central in the conversation.

I’ve used sonar for a long time as a developer and I’ve become accustomed to reviewing suppressed warnings as part of code review. When we separate what’s suppressed from that review process (move that info into the sonar ui from the code) it certainly cleans up the code (less annotations) but obfuscates why sonar analysis passed. To me it seems like if we’re going to integrate sonar with the PR workflow, we ought highlight things that indicate WHY it passed. I think resolutions are good for highlighting that.
I may comment on a particular line and suggest marking it a false negative. It’d be nice if I could verify, without leaving github, that my comment was addressed as requested.
I don’t think it’s a trust thing either. Rules such as sonars drive alignment on standards. If developers arbitrarily bi-pass them here and there, even with no ill intent, you end up with inconsistent data. You can’t really stop that if you’ve chosen for developers to have the keys (and we have) but at least you could have the conversation if you reviewed the PR.

I’ll make a note to bring this over to the feature request area with similar text.

Thanks for listening.

1 Like