Automatically turn on Pull Request Decoration in projects

Running SonarQube DE 8.4.2 with GitLab, self hosted.

As mentioned in Is it possible to automatically turn on Pull Request Decoration in projects, pull request decoration must be activated in each project. It requires costly repetitive manual actions or operating custom scripts to automatically update project configuration. Which is a shame, given the rest of the process is really nice.

Would it be possible to improve the process to turn on pull request decoration for all projects or if decoration could be activated by setting a parameter from scanner ?

Pre 8.x third party plugins relying on preview mode to decorate pull request were nice enough to not impose a such cumbersome workflow. It would be nice that a now commercial feature is as easy as it previously was.

You don’t have to set up project level pull request decoration, there is also global level configuration:

My understanding is that ALM integration is a global level configuration. But enabling merge request decoration is a project level setting. Documentation, my test and linked post seem to agree on that.

Hey there.

In SonarQube v8.5 it will be possible to import projects from GitLab (MMF-2080 / MMF-2081 / SONAR-13630) to provision projects with Merge Request Decoration already enabled with the required details.

I hope this ends up being a helpful feature for you!

Hi Colin, thanks for the links and good to know you hard working to streamline configuration for both small and large companies :+1:

My understanding of MMF-2081 and SONAR-13630, is that an action in Sonarqube UI or using web api will still be required per project (or initially on a set of project). If my understanding is correct, it still seems a bit cumbersome for our use case. Were are a small company with many repo, several hundreds, and high repo churn (new project are created on a regular basis). All our projects use a template Gitlab CI pipeline and thus an ideal workflow would be to automatically creates Sonar project on (a|first) master branch build which would automatically enable PR analysis etc. No need to fiddle in Sonarqube UI at all.

Hey there.

To be honest, on our side, we really do not favor auto-provisioning from analysis as a good practice. It tends to create many projects that just get abandoned and leaves minimal governance over things like project key naming, the right tagss getting set, permissions that get applied, and initial configuration.

Specifically, with Project Onboarding (provisioning in the UI after connecting to an ALM), we also believe having a tight link to the ALM opens up many possibilities in the future for even cooler integrations.

And, it’s totally your prerogative to disagree and suggest something different. :slight_smile: I just wanted to add some color about the work that’s in progress.

Sonarqube being your company product, I can understand this point of view :wink:

I do agree that tight link to the ALM is key and that’s exactly my point. ALM is where we manage repositories, permissions and build pipelines. Developers create a project, pick a build pipeline stereotype and that is it. Sonar projects should be automatically created and configured by the build pipeline. Any additional action, even worst in a another tool like Sonarqube is an annoyance.

Gitlab pipeline maintainers can automate using web api, but it would much more convenient to just pass a few parameters to the scanner and be done.

Perhaps that is a difference between gitlab and azure devops?

We use azure devops in my org, and as long as the user used for pr decoration has permissions on the repo pr decoration will work, no need for per-project settings.