Hi Tom!
This is in fact what I’m doing currently (great minds think alike )!
I can say a bit more about my integration with Azure Pipelines with this approach:
- first I execute
SonarQubePrepare
on agent, that sets theSONARQUBE_SCANNER_PARAMS
variable with all the params required (like branch name, pull request variables, authorization from Azure’ Service Connection etc.). - I create the ‘intermediate’ docker image with all the sonarQube tooling (including Java11)
- (having the sonarqube scan execution stored as a script) I pass the
SONARQUBE_SCANNER_PARAMS
todocker run
under exact same name, sodotnet sonarscanner begin
anddotnet scanner end
processes pick up most of the params automatically from this environment variable - I capture the
report-task.txt
and copy it from the docker to the location on the build agent where theSONARQUBE_SCANNER_PARAMS
defines the file to be, thanks to that… - …
SonarQubePublish
picks it and publishes the result, so I can have the QualityGate integration with the pipeline and pull request
This is most elegant solution I could find so far.
More than the performance/time I care of is the true result of the scan As I said, I was more afraid seeing that different sdk and different msbuild could be used for the original build and for the scan.
Hope it will help somebody in the future!
I’m also open for improving the way I configured that.
Take care!
Paweł