Sonarcloud analysis registration not always cleaned up properly

We are experimenting with integrating sonarcloud in our build pipeline on azure devops. We are using private agents, and sonarcloud analysis is now enabled for some jobs in our build process. However, it seems that the registration for the msbuild integration for sonarcloud is not always cleaned up properly. We now have random build jobs failing because they run on an agent that has previously run a job that enabled the sonarcloud integration for msbuild. We are NOT running parallel builds on agents, so that is not the issue.

This is a real showstopper for us for using sonarcloud. We cannot simply use manual scanning instead, because this would cause us to los the ability to scan all projects that are actually built in the job that is running. Using inclusions and exclusions would be a very tedious job because of the amount of projects and their locations

Is there maybe something we can manually do to remove the global registration as an extra step in our build job to make sure it is actually removed.

Besides this, I think it is a really bad practice to make changes to the global agent configuration in a build job, exactly because of these unwanted side effects it might have to subsequent jobs on the agent

We would really like some kind of response to this. As stated in the description, this is blocking us from integrating sonarcloud

Hi @PaulVrugt

Which kind of pipeline are you using ? YAML ? Classic editor ?

Thank you.

We are using yaml


Can you try to play around with this property at job level ?

- job: myJob
    clean: outputs | resources | all # what to clean up before the job runs

Its cleaning up few resources before running another build (actually and the end of a pipeline), it might help wiping out few things Sonar-related.

Let me know.


I can try, but this is a bit difficult. Even if this solves it, it would mean that we have to add the clean option to ALL pipelines in our organization, because it might be that the agent running the job has run a job using sonarcloud before. So it doesn’t really sound like a feasible solution

Fair enough. Can you check, once a pipeline has been executed, that you have/not have a SonarQube.Integration.ImportBefore.targets somewhere in the agent filesystem ? (If it’s a windows machine it could be also installed in either of the MSBuild directories)


I’ll re-enable the sonarcloud integration, but I have to warn the rest of our department about this, so they know what is happening if they encounter failing builds. I’ll see if I have time to check this tomorrow. Once I have results, I’ll check back here

1 Like

Just and update to keep this warm. I’ve re-enabled the analysis and am now waiting for the issue to occur again, but of course, if you want it to happen it doesn’t happen, so it might take a while before I can answer your question :slight_smile:

1 Like