No Badge image preview on privately managed Gitlab

SonarQube Server / Community Build
,
1

Hello. We have set up our SonarQube and SonarScanner on our privately managed Gitlab server. Our VM IP address is 192.168.52.144

On the same VM machine that our Gitlab server runs, we also have SonarQube instance and Sonar-scanner docker image.

Everything seems to work fun and I have managed to analyze the project without any issues.

The SonarQube generated the following URL for the Sonar Status badge:

http://192.168.52.144:9000/api/project_badges/measure?project={PROJECT_NAME}&metric=alert_status&token={TOKEN}

Note: I have replaced my actual project name with PROJECt_NAME and token with TOKEN just for security reasions.

When I go to my Gitlab and type in the following Badge Image URL, it shows up as No badge image in the preview:

image
image654×148 14.4 KB

I have also tried to replace the IP with the localhost:

image
image755×152 14.4 KB

If I just simply type this URL in the web browser, I can see the badge just fine:

image
image1259×117 11.9 KB

I would appreciate any feedback on how to get the badge to show up properly on my Gitlab repository. What could be an issue?

3

Hey there.

I tried it out with GitLab + a local SonarQube Server and it’s working just fine for me.

If you open up your browser’s dev tools at this point:

Do you see any specific errors?

4

Thanks for suggesting to check the dev tools.

It prints an error:
This request has been blocked; the content must be served over HTTPS.

if I add https, I get error:
ERR_SSL_PROTOCOL_ERROR

Is that an issue from our gitlab server? I assume thats something you will not be able to help us with? Is there any way to setup this to work with https?

5

I thought it might be something like that.

I’m not sure if that’s coming from your browser or GitLab itself. In any case, serving your SonarQube server over HTTPS is a good practice. We do offer some documentation to get you started – but you should use whatever is most commonly used in your org (Nginx, Apache, IIS…)

6

I have read the documentation and I dont believe I have understood a thing about setting up SonarQube via the HTTPS.

I remember setting the HTTPS for our self-managed Grafana server and it was a 2 step task:

  1. I have been provided certificate and key by our IT team.
  2. I have configured grafana configuration file to link to the .cert fand .key files and have enabled the HTTPS.
  3. I have restarted the Grafana server and was able to run it via HTTPS

Is it not simmilar in this case?

7

It is not really similar. SonarQube requires users to set up their own “infrastructure”, like a standard reverse proxy, to manage HTTPS for the SonarQube server. Most users are already doing this in order to visit their SonarQube server over http://sonarqube.foo.com rather than http://sonarqube.foo.com:9000.

In the past, SonarQube functioned more like Grafana does. The downside to that approach was that whenever a vulnerability was found in the embedded proxy, users had to wait for a new version of SonarQube to be released, rather than being able to update the software on their own.