Azure DevOps Pipeline Integration to on-premise SonarQube using cloud build agent

[mw-sfg (Mike West)]

Version: SonarQube Enterprise EditionVersion 8.9.8 (build 54436)
Deployed: on-premise (specific technology not really relevant in this case)
What do we want to do: We have Azure DevOps pipelines that are using the cloud based build agent that we would like to hook up to our on-premise SonarQube using the SonarQube ADO plugin (GitHub - SonarSource/sonar-scanner-vsts: SonarQube TFS/VSTS Marketplace Extension). Our on-premise Sonar is NOT externally exposed, thus we need a route to get to it. One potential solution to this that we can easily secure is to utilize Azure API Manager to secure the route from ADO into our internal network. This however assumes that the SonarQube ADO plugin uses the Sonar web API’s and identifying which API’s it is consuming to define in the manager (have to define them as some are get’s and some are post’s). An OpenAPI Spec would make this easier.

So simplify the question: Is it known what API’s what the ADO/VSTS Sonar Scanner plug-in requires access to?

Secondary question, has anyone gone the extra mile and created at least a skeleton OpenAPI Spec for the Sonar web API’s?

[Colin]

Hey there.

I can at least point you to this existing advice:

Connect to Github Action without externally exposing entire server

Hey there. Surely some DEBUG level logs will reveal to you each API call that the scanner makes (add -X under args), and you could derive the list of allowed endpoints from there. And, these endpoints could change from SonarQube version to SonarQube version and shouldn’t be considered as an API (if they change, we aren’t going to make noise about it). Typically when an organization has such requirements and doesn’t want to move their SonarQube instance the cloud, we would suggest using self-h…

I don’t have anything to share about an OpenAPI spec (at least there’s nothing officially)

Make sure you upgrade to SonarQube v9.9 LTS soon, not only to benefit from our Best LTS Ever™, but because soon we will systematically ask users to upgrade when they ask questions about earlier versions of SonarQube, which are now considered unsupported.