Projects only get default permissions template at set up phase

Hey, folks!

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):

  1. We create a custom permission template, giving it a name and a key pattern
  2. An user follows the path: Create project → Gitlab → Clicks on “Set up” for whatever (s)he wants from the list of available projects
  3. The imported project gets applied the permissions template, based on project’s key pattern

What happens:

  1. The onboarded project gets applied the default Permissions Template
  2. 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”? :stuck_out_tongue_winking_eye:

Any kind of help here (or just pointing us in the right direction) would be very much appreciated.

Thank you!

Hey there.

Thanks for the detailed post! :slight_smile:

It sounds like what’s not working is this:

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)

Hi, Collin!

Exactly that is not working.

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. :grin:

Thanks for your interest in this issue!

Thanks for the follow-up.

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).

Well…this is dumb (from me)! :disappointed_relieved:

I did try variations of the regex pattern. I even used online helping tools, like RegExr: they returned matches with the test strings.

Anyway…TL;DR: your recommandation works.
It was, like many times, a classic PEBCAK case. I guess I need to step up my Regex game. :grin:

Thank you! I very much appreciate your help!

PS: Problem solved, as far as I’m concerned.