FYI the SonarCloud/SonarQube Azure DevOps tasks are wrappers around the lower-level Sonar Scanner for .NET. The mapping between the Azure DevOps yaml task names and the scanner equivalents is as follows:
- SonarQubePrepare/SonarCloudPrepare →
begin - SonarQubeAnalyze/SonarCloudAnalyze →
end - SonarQubePublish/SonarCloudPublish → no equivalent. This task waits until the SonarQube/SonarCloud server-side part of the processing has finished so it can post the results to the Azure DevOps build summary.
Almost - if the SonarCloudAnalyze step isn’t run then the second Sonar integration targets file that is in a pipeline-specific location won’t be deleted (there is more info in this old thread about what the two target files are for).
If you have Sonar verbose logging turned on you should see something like the following in the SonarCloudAnalyze logs:
So if a build step fails/skips the SonarCloudAnalyze but the pipeline continues regardless and builds other MSBuild projects/solutions, then those builds will pick up the targets and be analysed too.
Similarly, if you are using self-hosted build agents, future builds of the same pipeline will pick up the targets.
There are a number of potential workarounds:
- use one of the Azure DevOps
cleanoptions to clean up the agent machine as @mickaelcaro suggested above (you would only need to set the clean options for the pipeline running the analysis, not every pipeline). - add a script step at the start of the pipeline to delete the
.sonaqubefolder and everything under it
There are a couple of other hackier workarounds involving the SonarQubeTargetsImported build property that are described in some forum posts, but I’d try the other two workarounds first.