Looks like sonarqube does not get the gitlab URL and I see no way to configure the gitlab URL in sonarqube. At least it’s undocumented.
The result is, that no sonarqube information arrive in gitlab and the mergerequest stays green without any hint about the failed quality gate in sonarqube.
Hi, welcome to the community forum! Gitlab URL (and other variables) are automatically detected by the scanner during the analysis, so there is no need to provide them. Please remove all your -D arguments.
Also, please use then documented env variables for the url and token, as described here : SONAR_TOKEN and SONAR_HOST_URL
My issue was I was using a custom entrypoint script (that was based around the old community gitlab plugin). Once I reverted to the normal one, this started working properly.
We use SonarQube 8.1 developer edition. I have configure Gitlab ALM in General Settings with a working token.
As far as I understand, it is because only gitlab CI is currently supported and we use jenkins to build our app, am I right @pierreguillot ?
Do I have to wait for this ticket https://jira.sonarsource.com/browse/MMF-1901 or is there a workaround to set missing parameter by settings some environment variables or giving parameters to sonar scanner ?
Yes you are. The workaround would be indeed to provide the expected Gitlab CI environment variable that are expected by the scanner, but i would not advise you to do that, as it his highly likely that we complete MMF-1901 for SQ 8.1, and you would have to change your implementation again in 2 month.
So can I expect the MM-1901 to be live in SQ 8.2 or 8.3 ?
If not, maybe you can list the needed environment variables. Since we used a library for our CI in Jenkins, we can easily configure the things for all of our projects.
Could you publish the parameters to get this working?
Though I understand you are planning to implement MM-1901 I can work around this now using a jenkins pipeline library, and would prefer to do so as this is an important feature.
@pierreguillot now that’s sonar 8.2 is released I try to use the new feature and it works \o, thanks.
But I have one more question, can we configure “Configuration Name” and “ProjectId” using system property that we give to the sonar scanner instead of configuring each project ?
That will allow us to do nothing for new project an for existing project
I’m watching this thread for several months. I have same question as @guillomep.
Is it possible to set “Configuration Name” and “ProjectId” using environment variables or scanner parameters? It would help us to automate process of creating and configuring projects without manual steps
Yup that was discussed during the implementation, and we decided to not go with it. The idea is that we want to avoid the scanner to be able to define configuration that require admin privilege on the project. That’s the kind of “auto-magic” feature SQ try to avoid. I personally think that auto-discovery and auto configuration would be really useful. I pinged our dear SQ PM @Chris to discuss this.
Hi there, I didn’t want to create another thread since I think my issue is relevant to this one.
I’m using Jenkins with SonarQube 8.1 Community Edition, and cannot get the PR decoration work in Gitlab. Reading through this, I understand that it works auto-magically from GitlabCI because it can detect/read the different environment vars provided by GitlabCI (described here).
Unfortunately, I am not able to update SQ because of plugin compatibility, but am still trying to get Jenkins to decorate the relevant MR/PR in Gitlab (on-prem). Is it possible to get sonar-scanner to run from Jenkins, but think it’s running from GitlabCI with the presence of the environment variables it normally expects from GitlabCI? If so, could someone tell me which specific variables need to exist?
I tried to use @kszpakowski’s API call, but when I used the following URL:
Where sonar-host is the URL of our internally hosted SQ 8.1 instance, project is the name of the project in SQ, and project_id is the project_id of the repo in Gitlab.
Unfortunately, even when logged in as admin, that API call returns the following error:
{“errors”:[{“msg”:“Component key ‘project:login-service’ not found”}]}