We’re doing the first steps in our organisation, in regards of introducing SonarQube. Which means that, at leas for now, the evaluation is based on the Community edition.
For deployment, we’ve opted for a simple containerized form (using docker-compose), with an NGINX doing the reverse proxy resp. SSL offloading stuff and SonarQube resp. Postgres running on the same Docker network, not being exposed to the outside world directly.
The used container image tags are as following:
NGINX: 1.25.1-alpine
postgres: 15.4-bookworm
sonarqube: 10.1.0-community
The authentication is handled by our Gitlab instance, because (in part) we also wanted to take advantage of the automated group sync. Of course, the Gitlab DevOps Platform Integration is also set up. So far, so good: everything works as described in the docs (and whatever else one could find by googling).
The part where we’re having dificulties with, is applying the permissions templates at the time of project onboarding in SonarQube.
How we’ve imagined it should work (but it doesn’t until now):
We create a custom permission template, giving it a name and a key pattern
An user follows the path: Create project → Gitlab → Clicks on “Set up” for whatever (s)he wants from the list of available projects
The imported project gets applied the permissions template, based on project’s key pattern
What happens:
The onboarded project gets applied the default Permissions Template
A global admin can, in a sequent phase, apply the desired template by going to Administration → Projects → Management → Apply Permissions Template (on the desired project). This works fine; the correct permissions are applied like we want them to have
Is this an expected behaviour, when one uses the DevOps Platform Integration path? Did we miss some sort of relevant piece of information in the docs and we’re trying some setup wich isn’t suppose to be working anyway? Did we hit a case of “It’s not a bug, it’s a feature”?
Any kind of help here (or just pointing us in the right direction) would be very much appreciated.
Have you managed to configure a project key pattern that matches the automatically generated project key from the project onboarding wizard? (colin_myproject_AYochOUpqcZUCmnGQfms to give an example from my instance)
From my observation, when used with a Gitlab instance, the generated project keys do have a pattern…
If the to-be-onboarded project resides in https://gitlab-fqdn/abc/project-slug, then SonarQube will attach a key that looks like ^abc_project-slug_some-apparently-random-string.
This was very helpful, because we could create simple patterns in permission templates. Based on my abc-example above, such a regex would be ^abc_ (and the desired group-/user-permissions, of course)
Like I wrote in the first post: this works just fine, but only if we apply the template after the project is onboarded in SonarQube. The only “hickup” is that, in the first phase, such an imported Gitlab repo gets applied the Default permissions template.
Now…if you tell me that this is to be expected in this scenario, then I’ll drop it and start thinking of other ways of automating it.
It’s just…I got the feeling that it should have been working.
I’ve just checked on my instance and permission templates get applied on projects created via the onboarding wizard (I set the catch-all .* pattern)
However, the regex ^abc_ will actually only match the string abc_
If you want to match a project key that starts with abc_ but could have anything after it, you would want a regex like abc_.* (catching any character any number of times).
