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?
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?
we are using that Gitea-Jenkins-SonarQube combination, too.
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?
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
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
Can you tell me what parameter you feed to the analyzer?
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.
Thank you for the suggestions Steven, they’ll be very helpful when we evaluate the developer edition
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
I’m successfully using the Developer Edition trial at the moment with PullRequests from Gitea (via the parameters you mentioned and from the docs)
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 :-/
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?