We are using the current version of SonarCloud linked to our Github repositories. I presume that like many other companies, we give our developers a fair amount of runway to get their jobs done easily, but within SonarCloud there are project-administration features that we do prefer to be managed by team-leads or managers.
One thing that is a bit of an annoyance for us is that it is not currently possible for a non-project-administrator to configure our CI/CD tool (TravisCI or CircleCI etc) to run a Sonar analysis and report back to SonarCloud because the project’s secret token is ONLY able to be accessed by users who have project-level “Administer” permissions even if they have “Execute Analysis” permissions.
Ideally it’d be great if you have access to at least view the token on the “Information” page in the project if you’re allowed to “Execute Analysis” for that project. That way we could give our engineers the ability to grab that token and set up CI/CD as-needed without either giving them the “Administer” permission level or making them wait on their manager to retrieve and send them the token from the SonarCloud administration pages.
I think something that needs to be clarified here is that tokens are tied to users, not to projects, and a quick test allowed me to configure analysis for a project while only having the Execute Analysis permissions.
You’re right – for a project that has been configured, there’s no way to retrieve that original token (which is good, because it’s basically equivalent to a password for the user who it was generated before). However, nothing stops your user with the correct permissions from provisioning a new token for their account to use.
So this type of analyze-project token can be gathered/set/generated without having access to the Administration menu of a project? I’d ask how you would get to this type of configuration page on a project without “Administer” access.
That’s a fair point Rick – for those users without Admin permissions on the project, those tutorials would only be available at the time of project creation before the first analysis.
I’m curious about this point –
Can you clarify what those specific features are? That would be really insightful for us.
I guess what I mean is that ideally the ability to create a token needed to perform analysis would be tied directly to the permission to “Execute Analysis” which I have granted to individual engineers. Other permissions like Administering Issues, Security Hotspots, and Project Settings we may want to leave to team leads / managers and other administrators - not just to prevent individuals from saying bugs or security problems are fixed when they aren’t, but also to limit the cognitive load on our developers.
