We have tested with patterns matching our permission template and the finding was that if the key name matched the rule pattern then we get the error but if we created a project with key name not matching any patterns in permission templates then it gets created. As a workaround we created a few projects manually with wrong key names and then updated the keys afterwards. Please note that our organisation key has a hyphen (-). And it was maintained in the failed and successful scenarios. Project names didnt matter, it was the project key that caused this issue. Let us know if you need any more detail. But hope this message shows how you can reproduce this issue at your end. We have tested this multiple times on 18th March.
2 Likes
Thank you @dragan and @AjithJohn for your insights!
From our internal investigation it looks like what you’ve run into is an expected behavior but without the proper communication to the user:
When you create a project, SonarQube will compare it with your permission templates and if more than one of these templates match the project key, it will fail but without returning a proper error message. Can you check if you have multiple permission templates that could match on the same project keys, please?
We’ll consider that to improve our product and make sure we give good feedback on error. In the meantime, I’ll consider this thread as resolved.
Don’t hesitate to come back to us if you have more feedback
Cheers!
1 Like
Ambroise, the answer is no we dont have permission templates with same pattern in more than one of them. Try this on another instance at your end and you should see the same error. And this is a new issue which happened through some change introduced at Sonarqube cloud recently I am sure. So, if its a feature then it should be considered a bug. If you have any ways to connect with us then we could show you how this is happening.
Hi @AjithJohn,
The issue is not with multiple permission templates having the same pattern. The issue is when your project key is matched by multiple permission templates.
In my case I reproduced the issue (with Azure DevOps) the following way:
- Create a permission template with rule `.*ambroisechristea.*`
- Create a second permission template with rule `.*project.*`
- Try to import a project named “project0” from my organization “ambroisechristea”. In this case SonarQube will try to create a project with the key “ambroisechristea_project0” (AzDO organization key + ‘_’ + AzDO project key).
- The computed project key will match both permission templates, raising an error as we don’t allow this.
Could you confirm that on your side multiple permission template rules match the project(s) you tried to import?
Thank you
We manually tried to create the project to test this on 18th March and we created projects with keys that touched upon one template rule at a time. But we also have this default project template that looks for all key patterns (.*) to avoid us losing access to any project people may create with a non standard key pattern. Do you think the new changes at Sonarcloud finds this as an issue now? We had this Default template from the beginning of this Org and never had an issue before this.
I cannot at this time confirm if this behavior is due to a recent change or not, sorry about that.
Thank you for sharing more details on your configuration. What I propose is that you remove the “Project Key Pattern” from your “Default template”. That way this permission template will be default for any new project not matching another permission template rule, and as your current default template doesn’t enforce any format (`.*`) this shouldn’t change anything to your permissions configuration.
Just in case, here’re the steps:
-
Edit your default template by opening it’s “Update details” window:
-
In the now opened modal window, empty the “Project key pattern” field (and save the changes by clicking the “Update” button):
If you don’t have any other permission template with “conflicting” rules, this should solve your issue.
1 Like
About the rename to fix the provisioning error: I didn’t do it myself, but the rename was not formatting- or special-character related. Probably something like adding a “2” at the end and then removing it again.
Our impression was that something blocked the system on sonar side to newly provision a repository of that particular name, because of a mysterious failure the first time.
1 Like
@Ambroise your solution was applied to the default permission template (to keep it blank) and now we can create new projects in any name and matching other permission templates. Thank you.
1 Like