Add another pullrequest provider

Hello there,

is there any guidance on what to do to create a plugin to add another Pullrequest provider?

We’re using Gitea and I’d like to have at least some of the experience I can see on the features page for other providers.

Whats important to me:

  • Populate the branches dropdown with PR informations
  • Create whatever is needed on SonarQube to make the analysis of PRs possible

Is this something that I can do on my own?
Or is there otherwise an option to do these things with the SonarQube REST-API (e.g. a hook on the Gitea side)? If yes, what scanner parameter would I have to pass to make the analyzer recognize the PR?

Thanks in advance! :slight_smile:

Hi,
SonarQube is not designed to get support of additional providers through plugins. The support of ALMs like GitHub and GitLab is mostly for the decoration of the pull request with SonarQube issues. Other than that, it’s mostly a convenience to avoid additional configuration.
What CI pipeline do you use? Can’t you trigger the analysis of pull requests when a commit happens?

Hi,

is it enough to set some analysis parameter to get the drop down list populated like in the screenshot?

If so, what would be the parameter I need to set to get

  • PullRequest ID
  • PullRequest Description
  • Link to the PullRequest?

I have all information at hand, just need to pass them correctly then.

Edit: We’re using Gitea to host our repository and Jenkins as CI/CD-Pipeline

Hi Markus,

we are using that Gitea-Jenkins-SonarQube combination, too. :+1:
Are you trying to scan PullRequests created by Gitea with SonarQube or do you try to decorate them in Gitea like it is possible with GitHub and other providers?

Best regards,
Steven

We’re currently using the Community edition, where I handwrote the decoration of pull requests (e.g. the commit status as qualitygate) as explained here.

We’re looking at trying out the developer edition, but I want to know up front what I can configure so I don’t waste days on configuring it :slight_smile:

Populating the dropdown for PullRequests on the SonarQube project would be a good first step!
If this opens up easier integration with Gitea<-> (e.g. hooks on the SonarQube side to report a commit status) then that would be great too, but not needed :slight_smile:

Can you tell me what parameter you feed to the analyzer?

Hi Markus

We are using Enterprise Edition but with at least SonarQube Developer Edition you can analyse PullRequests as described here from command line or via Jenkins. Do you know the Gitea plugin for Jenkins? We are using it and it provides us environment variables containing values you can use for the SonarQube scanner to fill sonar.pullrequest.base and sonar.pullrequest.branch parameters.
With these information the scanner can do the “heavy” work for you creating the desired PullRequest analysis in SonarQube.

This Jenkins plugin also automatically decorates your commits in Gitea with its build status (pending, success, failure, general error).

At the moment we just have such Jenkins build resultd as commit decoration in Gitea. In the context of PullRequests such commit statuses are called checks which can be used to prevent PR merges on failures. SonarQube can send webhooks for analysis results to any endpoint. In your referenced GitHub comment it seems that you use such webhooks to report back to Jenkins. I recognized that those webhooks contain more information than Jenkins use and expose to the pipeline.
It should be possible to build your own decoration or even add comments in Gitea based on SonarQube webhook payload. As the webhook documentation describes you can provide additional parameters to the scanner (like commit hash). Those parameters would be included in the resulting webhook post. In that way you should be able to feed Gitea with your desired information using its REST API (and create comments). You described a quite similar way for commit statuses (PR checks) in you GitHub comment.
For our use case I will evaluate posting a SonarQube webhook and use it as Gitea PR check to prevent merging with existing SonarQube issues.

Best regards,
Steven

Thank you for the suggestions Steven, they’ll be very helpful when we evaluate the developer edition :slight_smile:

In the meantime Code Reviews via REST API were implemented for the next Gitea release, so I hope we can e.g. fork the GitLab extension for SonarQube and implement the same integration for reviews :slight_smile:

I didn’t know about this planned Gitea feature. This is amazing :smiley:. Please keep me posted about your fork for the GitLab extension.

I’m successfully using the Developer Edition trial at the moment with PullRequests from Gitea (via the parameters you mentioned and from the docs) :slight_smile:

Is there a way to also pass the Title of the PR as parameter to the scanner?
It sadly seems like if we can’t build a custom plugin for Gitea as real scm provider (like Github, GitLab, …) we can’t get the titles of the PRs into the SonarQube UI :-/

Hi. Totally missed your latest response. :grimacing:

As far as I know there is no way to pass a title or description for the PR through cli parameters to the scanner except for sonar.pullrequest.key, sonar.pullrequest.branch and sonar.pullrequest.base. The key must be unique so we cannot use it to pass a highly customizable value like subjects without risking collisions inside of SonarQube.

What would be the benefit of having the title of the PR in SonarQube UI when you already have the PR number as identifier?