Azure Devops: not publishing quality gate task to job results

SonarQube Cloud
,
1

My Quality Gate results are not being added to the DevOps pipeline results. I see this in the logs for the publish task:

##[warning]No analyses found in this build! Please check your build configuration.

On further investigation, this seems to be related to our use of GitVersion in the pipeline to change the build pipeline version to be semver-compatible.

In the “Run Code Analysis” task, I have this debug line:

17:30:59.315 DEBUG: Report metadata written to D:\a\_temp\sonar\20220303.1\34e5fdde-8afe-02dd-875a-e6f7d549470b\report-task.txt

See that 20220303.1? That’s the initial version assigned to the job.

In the Publish Quality Gate results task, there is this debug line:

##[debug][SQ] Searching for sonar\1.0.2\**\report-task.txt - found 0 file(s)

See that 1.0.2? That’s the semver-compatible version that gitversion assigned.

It looks as if the two tasks are getting the current version differently.

Any idea how to fix it? I’m not keen on trying to add a task to change the version number for that publish task.

Thanks

Adrian

2

Hey Adrian.

I suppose I’m mostly curious where/when in your pipeline you change the version.

The logic that the Azure DevOps extension uses to determine where to search can be seen around this code:

So I suppose Build.BuildNumber is changed once the directories are already created (and those directories never end up matching).

(I’m not sure what a good workaround is yet, just want to confirm the details)

5

Hi Colin

Thanks for the reply - that gave me enough of a clue to figure out what’s happening … although I think that SonarCloud … could do better :slight_smile:

Here’s my original pipeline, annotated:

image
image328×529 16.1 KB

The line highlighted in pink is where the version number is changed. As you can see, it’s well before the actual analysis and result publish. Importantly, though, it’s after the initial preparation of Sonar Cloud.

Moving that prep step down below the gitversion execute step solves the problem!

So … here’s my assumption:

  • As far as analysis is concerned, the version number is determined during the initial preparation of SonarCloud
  • The publish step, however, doesn’t use any work done in the prep step, but examines the env variable again … by which time, of course, it’s changed.

So, moving that prep step to after gitversion solves the problem :slight_smile:

Hope that helps somebody else.

Adrian

2 Likes
6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.