Our team is one team among several teams across multiple companies, developing a large project. The management of the project requires the use of an established CI/CD pipeline using Jenkins. However, they will only authorize one person per team to have access to view the CI/CD pipeline, so the team cannot view the SonarQube results directly themselves. We are developing Java backend services using Maven. The CI/CD pipeline executes “mvn sonar:sonar …” for the code quality check.
Our work-around for the team is to utilize our own local SonarQube server that everyone can see. Thus, if the local sonar analysis is equivalent to the analysis in the project’s CI/CD pipeline, then the one person with access won’t be the bottleneck/single-point-of-failure.
The question is understanding how the SonarScanner for Maven works; what code analysis rules does it use. I understand that “mvn sonar:sonar …” runs its own sonar analysis on the local machine and then pushes up the rules to the server which stores and displays the analyses. Where do the rules come from?
Does the sonar-maven-plugin version define the rules? Thus if both pipelines are using the same version of the plugin for the “mvn sonar:sonar” step, then the results will be identical.
Does the plugin download the SonarScanner along with configuration from the server? Thus if both servers were using the same version and had the same rule configuration, then the results will be identical.
Other
Any suggestions on how to deal with this situation?
the sonarqube maven plugin is just a wrapper with sane defaults taken from pom.xml
it has to download the scanner plugins, i.e. Sonar Java … etc. once
Other !? don’t get it !?
I don’t quite understand your setting / environment !?
We have several network areas, but use only one Sonarqube Enterprise instance for all.
One principle of Sonarqube is that developers are responsible for the quality of their software.
So they should / must have access to their results and metrics in Sonarqube.
@anon67236913, the intension of my (1), (2), (3) was to capture which of these cases define how the rules are determined. I was thinking through how I thought it might work. I thought there were two main approaches: either (1) or (2). Then I added (3) because maybe it is done a different way.
Not at all
The maven plugin doesn’t define rules, that’s all server side settings (quality profile, quality gate).
Like all scanners the maven plugin just uploads an archive to Sonarqube server after scan has finished computed there.
Still curious about that additional local Sonarqube server !?
So if I understand correctly, this is roughly the process:
Maven plugin interacts with the Sonar server to download the SonarScanner from the server that includes the rules
Maven plugin executes the scan using the SonarScanner
Maven plugin uploads the scan results to the server
The important point is that the server defines the rules.
The reason for the local Sonarqube server is a work-around because of the restrictions that the project management has placed on us. Imagine this case:
I, as the only person with CI/CD visibility, creates a pipeline for a new service under development
The developers work on the service. They make commits, but they cannot see the pipeline results.
The developers call me up to say, “what does the Sonarqube results look like?”
I somehow give them info from Sonarqube
This is pretty bad, right? Project management should give everyone access to the CI/CD pipeline so that the developers can see their own issues in Sonarqube and fix them without me being in the loop. But they don’t want to do that. The project management is a different organization and we have little influence over their decisions.
So our work-around is to set up a local Sonarqube server that we can execute manually as part of each developer’s workflow. They fix their issues as they go along. Eventually they tell me that they expect their latest commit to be pretty clean so I check the Sonarqube results in the official CI/CD pipeline and confirm it is good.
The key is to setup our local Sonarqube server as close as possible to the server in the official CI/CD pipeline so that what the developer sees when he manually executes a scan matches what the official CI/CD pipeline shows.
This is the stumbling block, it doesn’t make any sense to prevent the developers access to Sonarqube metrics and scanning results of their projects.
You need to convince against your restrictions. Another way is to use the Sonarlint plugin available for all major IDEs to catch findings before pushing to git. That said they would need access to the related Sonarqube projects.
TL;DR your setup doesn’t make sense. Restricting the access for developers to Sonarqube metrics and results is contraproductive / simply wrong.
