Use Case of `sonar.buildString` parameter

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube - * Community Edition Version 9.3 (build 51899)

  • what are you trying to achieve
    I want to retrieve code smell results in analyses with a specific buildString value.

  • what have you tried so far to achieve this
    I created several analyses with different buildString values.

Hi, I want to retrieve code smell results in analyses by specifying buildString value. I could not find anything in the API related to this. Am I missing something? If we cannot do this, is there any other way that I can accomplish this except by specifying some dates? What is the use of buildString parameter?


Build strings aren’t tied to the issues raised in an analysis, only to the analyses themselves.

And no, issues aren’t tied to analyses either. So there’s no good way to get this.

The point of the buildString value is to allow you to tie Quality Gate status back to a particular build for traceability. It allows you to pass in your build number without impacting your sonar.projectVersion value (and thus accidentally resetting your New Code Period with each analysis).

For my curiosity, would you mind describing what you’re trying to achieve?


Hi Ann,

Thank you for your answer. It seems that buildString is irrelevant to my purpose. I want to get either all code smells on a single analysis, or the number of code smells on a single analysis. As there are many analyses, I am looking for a way to pinpoint a single analysis systematically by using the Sonar API. Is it possible? I had high hopes for buildString parameter, but it seems like I failed :grimacing:

(I would be OK with retrieving the new smells between the two analyses. If I have analyses a,b,c,d, and e, I want to get new smells between b-a, c-b, d-c, etc.)


If you’re looking for a count, you can get that from the api/measures/search_history service. You can see the values graphed on the Activity page. The only problem is that you only get the values for the analyses that are still on file. Housekeeping regularly cleans out old analyses that aren’t of particular note.

if you want the actual, specific Code Smells that were raised, you’re going to be even more disappointed. The docs describe how “new” issues are identified. But basically an issue is re-raised in each analysis… until it’s not. And then it’s Closed and eventually removed from the database. So if a new issue was raised on Jan 4th and fixed on Jan 5th, it’s already gone from the database, with no way to retrieve it except to re-analyze the historical state of your code. (And why would you want to do that?)

Even this will be difficult because if the 2nd analysis Closes issues, your net numbers will be low on new issues created because of those removed issues.

Could you explain why you want to do this?


Hello Ann, thank you a lot for the detailed answer. The reason is that I want to understand if code smells decrease or increase in pull requests by drawing some custom graphs. I don’t know if this feature exists in the paid versions, but I am using the community version.


Ehm… pull request analysis is only going to show new Code Smells. Unfortunately, issues Closed by a PR aren’t shown on PR analysis (we have a ticket in for that, but my Jira-fu is weak today and I can’t find it).

Your best bet is probably to pull numbers after each post-merge analysis. But again, you’re only getting net values. If I open 4 and close 3, the change is +1.


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