I’m attempting to query the SonarCloud API (https://sonarcloud.io/api/issues/search) for all issues that existed at a given git hash, or during a specific scan of the code, and I can’t figure out how to do it.
I’m performing the scans using the sonar-scanner.bat file, and am setting this at scan time:
sonar.analysis.buildNumber=$ANALYSIS_ID
I understand that information would be passed along to a webhook, but we aren’t currently using webhooks, just a script that queries the results at an arbitrary later date.
Is it possible to query for all issues found during the analysis $ANALYSIS_ID, or at the git hash that the scan was performed against? I don’t care if they were created by that scan, only if they existed in the code at that scan.
I do seem to be able to search issues by branch, and to manually force the branch to whatever value I like, but forcing the branch to a unique scan id is very much a hack I’d like to avoid.
It’s not possible to link issues to a specific analysis (unless it’s the latest analysis of a branch). While measures (# of issues, code coverage) are tied to analysis (until consolidated by housekeeping), issues are not.
Thank you for raising the importance of this information for you. May I ask you for which purpose you need to see the issues per analysis instead of per branch or per Pull Request? This would help us to maybe address your need in a better way. Thank you in advance.
I’m working for a medical device company. I’m trying to switch to your product, because I think the analysis it does is much more useful than the static analysis product we have been using.
However, because we are a medical device company, we have to submit formal static analysis reports as part of our FDA submissions that are based on the exact version of the code we built from. We often end up submitting a few more changes to a release branch after the final build for bookkeeping reasons, so we need to generate the reports from a specific git hash.
PS: Having Sonar Cloud generate the reports directly instead of having our own scripts query your API for the data to generate them would be even better… if it could generate them from a specific git hash and/or scanner run.
I think that managing “virtual branches” or gît tag is better then a workaround. This tags could help you to manage important gît hash, keeping report for them and not for all commit. Keeping too much data will impact database performances.
In your situation i will have some tags like release/1.2.3-final and release/1.2.3-bookkeeping.
For the semantic of version, we use SemVer 2.0.0.
Hello again Don,
Thank you for your further explanation regarding this topic. We really appreciate you took the time to share it. It’s not something that we consider for the roadmap at the moment but we’ll keep a record of this and continue to look out for similar requests. We’ll update this thread if anything changes.