Azure Devops: Sonar running on build BEFORE SonarCloudPrepare

SonarQube Cloud
, , ,
1
  • ALM used: Azure DevOps
  • CI system used: Azure DevOps

Hi,

In the yaml azure pipeline, we want to build some source with msbuild OUTSIDE sonar, so we do the following:

  • first step of the pipeline is the msbuild command (so no scanner)
  • second step is the SonarCloudPrepare@2 with scannerMode: ‘MSBuild’

It was working well up to this morning when we start seeing error in the first step while buildng:

     4>D:\DevOps_Agent\_work\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: The "IsTestFileByName" task failed unexpectedly. 
D:\DevOps_Agent\_work\1\.sonarqube\bin\targets\SonarQube.Integration.targets(245,5): error MSB4018: System.IO.FileNotFoundException: D:\DevOps_Agent\_work\_temp\0b6433eb-e468-472b-9b57-b69d680588ad\SonarQube.Analysis.xml

So Sonar is active… Do you change something?

Anyway the easy workaround is to inverse both step and remove the source from the analysis (sonar.exclusions), but the behaviour is very weird as if the usage of SonarCloudPrepare becomes mandatory?

Regards

2

Hey there,

I’d be interested in knowing what your full Azure DevOps Pipeline YAML looks like, and if you specify that the build workspace should be cleaned before each run.

3

Here what the Checkout is saying:
git config --get remote.origin.url
git clean -ffdx

So I think everything is fully clean…

What is exactly your question? Where the sonar information are stores? outside the agent folder?

Because we changed nothing on it was working before… and as you see the folder is clearly missing (so clean by the git command!)

4

Hey @Laurent

Sorry for the late response on this.

I tried to reproduce the issue (see this repo with this pipeline config and these pipeline logs) and was unsuccessful.

Am I missing anything crucial from the environment where you’re running into the problem? Are you still facing this problem?

5

Hello,

Thanks for the tests.
As we do inverse the step, we do not face the issue anymore…

Note that this pipeline is running regularly on each PR, it sounds like it keep the previous configuration but a git clean is done at each startup…

Anyway, we have a workaround.

Regards