Extracting taskID/analysisID from Maven (or other) build system with Sonar plugin under Jenkins

In my environment using:

  • SonarQube Developer Edition Version 8.9.7 (build 52159)
  • Maven Scanner plugin Version

I’ve run into an issue. Currently most of the builds, whether they’re C/C++ or eg. docker ones, can expose the task ID through specified report-task.txt file, which we can then utilise in further steps. However, when scanning with maven, I’m not seeing this file created. As such in our jenkins pipelines we need an alternative when dealing with Maven builds and Sonar. SonarQube documentation offers withSonarQubeEnv method in Jenkins to run analyses from within jenkins pipelines. This method is paired with QualityGate one. As per the explanation in SonarQube docu the former method extracts/gets the analysis or task ID, whether it is using direct jenkins analysis scan plugin or jenkins is calling eg. maven which then deals with analysis (eg. maven with goal sonar:sonar). This info is then passed to the QualityGate step for it to wait for proper callback. It does so by attaching the task/analysis ID to the pipeline context for the next step/stage to utilise… and apparently it works. How can I extract this pipeline context value on my own when running in jenkins, eg. to store it somewhere in later stages? How can I extract this info from my current pipeline eg. to use the aforementioned ID in later steps/stages to assign it to the artifacts produced by the pipeline upon final component deployment? Basically, how do I get this pipeline context manually?
Alternatively, how can I tell maven plugin to create report-task.txt file at my own specified location during the analysis? In C/C++ pipelines we’ve used our own specified by sonar.scanner.metadataFilePath parameter, but in case of Maven it does not seem to work as well, do I need to specify any extra scanner parameters for Maven scan to actually expose the details?
Finally, this pipeline attaching seems to be working when the Sonar scanner in maven is run without the quality gate params enabling it within the scan. If Maven Sonar scan is run with quality gate params/enabled, it seems the analysis/task ID does not get exposed to the next stage. Is this an error on our end or is this how it is supposed to be?


Could you explain what you want to do with the task ID? You mention attaching it to artifacts, but

a) task id and analysis id are different things, so it won’t work as a reference, long-term
b) even if it were the analysis id, you should be aware that analyses are cleaned out of SonarQube on a regular basis

Also, make sure you upgrade to SonarQube v9.9 LTS soon, not only to benefit from our Best LTS Ever™, but because soon we will systematically ask users to upgrade when they ask questions about earlier versions of SonarQube, which are now considered unsupported. :smiley:



when running SonarScanner for Maven = mvn sonar:sonar in Jenkins the report-task.txt is created here


1 Like

Basically, we have further steps that use task ID to get project/branch metrics, which then are reported to code security suite within a pipeline and are also attached as properties to artifacts.
I was looking for a way to either not use task ID, and possibly switch to analysis ID altogether, or to get task ID out of the plugins. Either way, I’d need to get metrics for the specific scan…

As to upgrade… yeah, we know of it, we’ve got it planned, but we have a few other things on our hands for the moment :wink:

Yeah, I found it and tried earlier. Just missed the fact that some DEVs have set in their maven sonar:sonar calls a preview mode, which basically meant no report task file created… as soon as i got it cleared, the task file creation has been obtained, and thus task ID is reportable.

Still, the plugins supposedly attach the task ID to pipeline context, as per your documentation. Is there a way to get this value out of said context so as not to base the task ID retrieval on a file that can be overwritten? Please be aware that we have parallelised pipelines with concurrent builds & sonar scans/analyses scheduled out of same workspace, so unless we specify temporary locations for the workdir in each parallel scan or have them known/altered prior to each parallel pipeline, the “hardcoded” paths may be overwritten between scan/analysis step finish and task id retrieval step commencing. Thus the need to get the task ID out of said pipeline context, which presumably would be the present and not altered as long as we’re in the same parallel “branch” of the overall pipeline.


A better strategy is to use the sonar.buildString parameter to attach your ID (presumably the full semantic version) to the analysis.

Unfortunately, you can’t search api/project_analyses/search by build_string, but it is part of the response, so you can filter the search results once you’ve received them (using a date filter?), and go from there.


P.S. I should have mentioned that a webhook payload will include the values of the metrics in your Quality Gate, no API calls necessary…

Yep, that’s a possibility, but frankly I was tending towards getting the task ID from the pipeline wherein the scan was done, so as not to have to go through project_analyses searches to get the metrics/measures for the scan/project.

Regarding webhook payload, do you know how to extract it/get it? My guess it is returned when sonar scanner is run without quality gate properties provided. In our environment we have some teams that keep using split approach with scan + qualitygate stages but we also have a lot of the teams that use qualitygate params directly within analysis… not sure if webhook payload can then be obtained. Regardless, I do not know how to extract said payload after the scan within the same pipeline for following stages anyway…


After server-side report processing is complete, the webhooks will automatically be sent to the configured addresses. The docs include a sample payload. Basically, it’s the QG status plus the value of each relevant metric and whether it passes/fails the criterion.

So you just need to be ready to ‘catch’ it & then parse the JSON.

Fair question & the details are going to vary by CI. Unfortunately, I don’t have ready answers for you.