Every action that is taken in SonarQube is driven by the Web API. There is nothing you can do in SonarQube that you cannot do using the Web API.
We put a great deal of effort into the UI and UX of our products and sincerely think that most actions should be completed there. Especially when it comes to viewing analysis results, the UI is the best place to view up-to-date information with the right context. We think it is much better that you give access to others to view analysis data within our products, rather than craft some export.
And, we recognize that there are common administrative actions where using Web APIs to help with automation makes sense. There are also surely some interesting reports not available in the UI where you would need to export the data from SonarQube.
A link to the Web API documentation for your SonarQube Server / Community Build instance can always be found in the footer of your instance. The SonarQube Cloud Web API is documented here.
You’ll find that most endpoints are properly documented, while some are not or are lacking in documentation.
If you’re not sure which Web API to use, you can reverse engineer what’s happening in the UI by diving into your browser’s dev tools.
Suddenly, it’s very clear from the Request URL which API was called. The Payload tab and Preview/Response tabs make it clear what query parameters are used and what the response was.
Hi Colin, i really like this explanation. I am not that much interested in frontend development and that made it hard for me to “grok” the easy way that Ann mentioned in some replies (how to eavesdrop on the Web API usage) For this, your howto helps a lot!
Concerning the below quoted paragraph (and combining it with your current survey question about “communitysm”) … maybe you might be able to find a way how to “channel” some energy concerning “common administrative actions”? I really would be looking forward to it! (because some lonely helpful threads really get easily lost in the sea of new postings).
Sadly, i was not able to find an easy solution … how to structure that? By tag? In its own “compartment” (e.g. smth like here)? I have no good suggestion to make
great post! This is exactly what I have been using for years to get in deeper with many tools.
I remember with a shudder the crappy browser tools of IE 11, but these days press F12 and start diving
I hope this is on-topic (enough), but I’ve been using both the Web API documentation and the network activity in the UI to help me with building automations for SonarCloud. The Web API is especially useful as it let’s me generate a typed client by inspecting https://sonarcloud.io/api/webservices/list. (I have a go-sonarcloud client which, in turn, is used to build a Terraform provider for SonarCloud.)
My question is now: how should I deal with either deprecated endpoints or endpoints that are missing in the webservices/list? I figure for missing endpoints I could open a feature request at https://portal.productboard.com/sonarsource/1-sonarcloud/ , though it doesn’t feel like a feature request.
As an example of where I’m having problems: there are two important endpoints regarding permissions that have been marked deprecated for well over a year, but they still work. The API endpoints that replace them are not registered yet in the Web API Documentation, though they are in use by the UI. I’m still using the deprecated API endpoints, simply because I can generate the client code for them. I’d have to do manual work to add support for the new endpoints, and I kind of hate doing manual work .
Do you have any tips for a course of action here @Colin?
I don’t see Activity option when am looking at pull branch analysis. can you please indicate how can I get what api to call to get coverage for a specific pull branch?
example: on gui url looks like this for me https://sonar-team.com/dashboard?id=product-pba&pullRequest=124434-9
seeing Gilberts “graphical” api-diff between 9.9 LTS and 10.3 latest here made me wonder:
How would i reverse-engineer those api-changes between SQ-Server-Versions?
Are there maybe some “versionized” world-readable docs that i could diff myself with tooling? Like OpenAPI-Docs that i could download as xml/yml/zml and diff via tooling?
edit: example for more context
my self-created api-tooling was created targetting an older SQ Version
i want to check if i can optimize anything.
what could i check, what changes were made that would make my processes better?
like in the example above:
It seems now one can set the new code period directly while creating a project
which means, i could shift functionality from the “project-confectionize-phase” :zany: to the project-setup-phase
We put a great deal of effort into the UI and UX of our products and sincerely think that most actions should be completed there. Especially when it comes to viewing analysis results, the UI is the best place to view up-to-date information with the right context. We think it is much better that you give access to others to view analysis data within our products, rather than craft some export.
For this, your howto helps a lot!
.
