Is is possible to determine the hashref for the code via the API?

SonarQube Server / Community Build
, ,
1

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?

2

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

3

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.

4

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?

5

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

6

Thanks for the guess Gilbert but that unfortunately didn’t return anything relevant.

7

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:

Selection_1263
Selection_1263498×708 11.7 KB

 
HTH,
Ann

8

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?

9

Hi,

Did you look at api/project_analyses/search?

 
Ann

10

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).

11

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

12

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.

13

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.

14

The branch parameter for GET api/project_analyses/search is internal, means use
https://yoursonarhost/web_api/api/project_analyses?internal=true et voilà

internal
internal775×269 9.79 KB

To see all use

web_api

2 Likes
15

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:

  • A time-based “best effort” match
  • On an unstable interface
  • With a user-defined override of the sonar.buildString setting which could already be used by one or more webhooks

I’m happy calling this one answered since there is technically a solution but :point_up: really doesn’t seem like a “good” solution.

16

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:

  • Job from Repo scan_my_stuff runs
  • scan_my_suff checks out the target repository
  • sonar is used to scan the target directory (which is a repository)
  • This means that the hashref should be of the thing scanned (target repository) not the checked out repo

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.

17

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