I have tried the new Gitlab PR decoration in sonarqube 8.2. It works but there are two things that blocks me using this features:
the first one is that we have to configure project by project the same configuration and the project id.
is it possible to send them directly to the scanner during analysis using system properties ?
why asking for the project id since it can be found using the API ?
our sonar is in a private network and so not accessible from internet, gitlab.com wants to proxy image and fail to so the message is badly displayed (see the screenshoot)
is it possible to inline image in base64 in comments ?
is there a way to have a FQDN only for static resource and use it in comments ?
This is not possible. If you want to automate this, you can use the SQ api endpoint api/alm_settings/set_gitlab_binding
Well, we need the project id to query the API. There is no way to match projects otherwise, except guessing by names or something. Not reliable. If you see another way to match projects without projects ID, i would be happy to implement it!
This is indeed a gitlab.com specific behaviour (for example, this proxy is not enabled by default when you install gitlab on-prem).
Not that i’m aware of
Not yet, but this is an idea we consider for incoming release of SonarQube
I would not say a gitlab problem, but yes this is a behaviour specific to gitlab.com
Okay for the call to the API to set the binding I will implement that.
You can find the project id by calling https://gitlab.com/api/v4/projects?simple=true&membership=true&per_page=100 and use the ssh_url_to_repo to find the project. Not sure if it match your requirements or if it resilient for all projects.
I tried to use base64 encoded image but it doesn’t work
So the usage of a specific FQDN for static resource would be great.
Maybe I have to open a issue on github about proxying images from a private network.
Well, we do not have that information. From the SonarQube application point of view, when considering a project, we have no information about the ALM.
The use case is different when using GitLab CI/CD, because the scanner read environment variables and can detect that the runner is GitLab. That’s why this project id property is not needed if using GitLab CI/CD.
You need project admin permission to call the API, yes. So if you plan to do it by script, the user need to be project admin of every concerned project. Or be global admin.
