I’ve been digging through the API for version 9 and I can’t figure out how to determine the git hashref (or other SCM system identifier metadata) for the code scanned by sonarqube.
The branch name is retrieved but branches move so knowing exactly what hashref was scanned is quite important.
Is there potentially another method for storing this information during the scan for later retrieval or an endpoint that I’ve missed?
Hi,
Welcome to the community!
I think you’re probably looking for sonar.analysis.[yourKey], which allows you to store extra information with any given analysis. I don’t think the data is shown in the UI…? Maybe on mouseover of the analysis in the Activity tab? But it’s available in the web services.
HTH,
Ann
Thanks. That would certainly work.
I had assumed that this would be standard information since it’s the only way to concretely correlate the scan results to the scanned item and that I was missing something.
Well, after setting some custom keys, I haven’t found a way to actually get them back out of the system via API queries.
A search of the API docs hasn’t really gotten me very far either.
Do you know which endpoint would be used to fetch the contents of a custom setting?
Hi,
never used custom properties so far, means just a guess at first glance
The docs for GET api/webhooks/deliveries have
Get the recent deliveries for a specified project or Compute Engine task.
Require ‘Administer’ permission on the related project.
Note that additional information are returned by api/webhooks/delivery.
Gilbert
Thanks for the guess Gilbert but that unfortunately didn’t return anything relevant.
Hi,
Okay, I was wrong. I was able to find the original spec, and these properties were only intended to be passed through to webhook payloads. And I’ve verified that they are there:
HTH,
Ann
If I’m understanding this correctly, then there is no way to determine the hashref of the scanned branch via the API at this time.
Or is there some way to use an internal Sonarqube webhook to inject this information back into the scan?
Hi,
Did you look at api/project_analyses/search?
Ann
OK, that does provide a revision but it’s the revision that the CI system sees and not necessarily the revision of the actual thing being scanned.
So, this would work for a limited use case but still doesn’t correlate the actual artifact and the data in the actual git checkout being analyzed.
There’s also no way (that I can see) to correlate the event data with component data (didn’t dig super hard though).
Hi,
I’m not sure what that means.
Uhm. Yeah. It’s the revision that SonarQube analyzed.
You do also have the ability to pass in - and this is stored with the analysis - sonar.buildString.
HTH,
Ann
OK, since api/project_analyses/set_baseline is deprecated, that seems to be pretty harmless as a data passthrough.
How do you concretely tie an analysis to a report though?
Would it be pulling the analysisDate out and using that as the search parameter? While this should work, it does seem to have a potential for race conditions.
I’ll give it a go though.
This almost worked the way I expected but the project_analyses/search endpoint only seems to be returning results for the default branch which means that the correlation still isn’t possible.
The branch parameter for GET api/project_analyses/search is internal, means use
https://yoursonarhost/web_api/api/project_analyses?internal=true et voilà
To see all use
Ahh, yep, that will do it, thanks.
I had kept that unchecked assuming that they were unstable interfaces.
So, in summary, the information can be gotten using:
sonar.buildString setting which could already be used by one or more webhooksI’m happy calling this one answered since there is technically a solution but 
really doesn’t seem like a “good” solution.
I just wanted to cover this point really quick.
In some scenarios, you have a build system that will run sonarqube from a different checkout altogether.
For instance:
scan_my_stuff runsscan_my_suff checks out the target repositorysonar is used to scan the target directory (which is a repository)I find this interesting because sonar is definitely pulling in the correct blame information from the target repository. It just seems like some metadata should be exposed from the thing being scanned that just isn’t.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.