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?
Any insight would be appreciated.