We’re using the latest SonarQube version in an on-premise install and I’m trying to understand the expected workflow for developers resolving issues via pull request decoration.
We use a pull request-based workflow where the developers make all changes in hotfix/feature branches, and then those changes are merged into the relevant permanent branch via a pull request. We are using Azure DevOps for SDLC, and the pull request decoration is working fine.
Our intent was for the developers to resolve any issues directly from within the pull requests in Azure DevOps, but I’m not seeing how to keep them from having to also go into SonarQube and resolve some issues there.
I guess what I’m trying to better understand is the level of integration between Azure DevOps and SonarQube, and the expected workflow for developers resolving issues. As the developers resolve each decorated pull request item identified, is there supposed to be an integration back to SonarQube to update that item there? For example, if a Code Smell issue is detected on a particular line of code, a developer may elect to mark it as Won’t Fix for a particular reason - but I’m not seeing the item get resolved in SonarQube. Should it be?
I understand if they make a code change and truly resolve the issue, then that would be reflected in SonarQube after it rescans and no longer detects it, but for these where they simply mark Resolved or Won’t Fix in DevOps, how is SonarQube supposed to know?
Hi @Kenneth,
From what I understand from your setup, the short answer could be : SonarQube server knows about issues in general when there is a new analysis. If you fix something in your code, then it will be detected and the issue will be removed.
About issues on Azure DevOps side : I checked and there is a synchro SonarQube --> Azure DevOps (when you mark an issue as Won’t fix in SQ, it will be marked as Won’t fix in your PR). But it doesn’t work as Azure DevOps --> SonarQube. This is a technical limitations on Azure side.
Thanks for the information. Yes, I believe you did answer my question and confirm my theory.
As for a pain point or how we would expect it to work, I guess it’s really more of just a learning curve for us. We’re still very much in early stages of integrating SonarQube into our workflows and applications.
I suppose in a perfect world, the integration between SonarQube and Azure DevOps would be two-way in nature, and allow the developer to resolve all issues without ever having to go into SonarQube. It certainly is helpful for them to see the issues decorated in the pull request as they can then quickly make the necessary code changes and resolve as many of them as they can without ever going into SonarQube. It’s only the issues that may be deemed false positives or can’t/won’t fix for some reason that they’d then have to go into SonarQube and status appropriately. I was hoping by them statusing those within the pull request that it would update SonarQube as well, but I understand you’re saying that’s not possible due to an Azure DevOps limitation.
I think the bottom line for us is:
Resolve as many issues as possible with the necessary code changes identified in the pull request
Go into SonarQube and status any outstanding items that can’t or won’t be fixed appropriately
Thanks you very much for the information - it is very helpful!
Just wanted to echo Kenneth’s sentiments… The two-way integration would be ideal… but understand its a limitation. In light of the limitation, perhaps there might be a way to make it more clear that the integration is 1-way? We find ourselves using the pull-request decoration to facilitate conversation around some rules, and once we’ve landed on our outcome (such as wont-fix), it wasn’t obvious that setting “wont-fix” on the PR decoration wouldn’t report back to SonarQube. Unfortunately I don’t have any good suggestions on how to make that more apparent…
