- ALM used: GitHub
- CI system used: GitHub Actions
- Scanner command used: sonar-scanner Action
- Languages of the repository: Doesn’t matter
- Error observed: Token used to set up project in CI/CD expired when that user left the organization
- Set up scanning using GitHub Actions as a user, then remove that user’s access
- Potential workaround: service accounts or non-user specific tokens
Indeed – if a user is removed from an organization or has their account deleted, the associated tokens will stop working as well.
Can you clarify the goal of this thread? To propose that SonarCloud offer tokens not tied to a specific user? To let others know that they can try creating technical accounts so they don’t face this issue? The intent isn’t clear.
I think this is the exactly the problem we are having. When a user for example uses his account to set up a project’s CI/CD pipeline and that user leaves the org later on, his token gets revoked (as you said), causing the pipeline to fail. We want to be able to create access tokens that are not user-specific (ex. on org level).Also, creating a service account for each project/team will cost a GitHub licensed user for each in our case, which we also want to avoid.
Also, when we’ve recently had a similar scenario, we struggled for hours trying to troubleshoot error: ERROR: Could not find a default branch to fall back on . At the end, we found that this is due to the user’s token being revoked because he left the org. So it would also be helpful if that error message is made more relevant and meaningful in case users run into this issue. Thanks!
Thanks for the explanation. I’ve moved your thread to our “Product Manager for a Day” category!
Looks like several similar requests have been submitted before:
There was also a feature added to the development roadmap a few years back but never implemented: SonarCloud Community - Issues - Jira
Any chance this will be prioritized on your roadmap in the near future?
Hello @mikefede ,
You can follow the progress of this topic on the following card on our roadmap: https://portal.productboard.com/sonarsource/1-sonarcloud/c/390-organization-and-project-api-tokens .
There are no short-term plans to work on it. Getting more feedback on the feature will make it easier for us to prioritize it in the future though.
There’s a secondary request that @skhalaf21 mentioned in his post that could be considered for a shorter term improvement. The error message we get when using a token that’s no longer valid doesn’t make it easy to understand what the problem is. Improving this error message in the short term would help us diagnose the issue when we have invalid tokens due to users leaving the organization and will still be valid if you implement org / project scoped API tokens.
Another issue with this is if organizations have some people that are admins in SonarCloud - if they create a token, it gets all the permissions of the user. Which means that administrators cannot really create tokens intended just for project analysis, because those tokens could change system settings as well.
A workaround can be to have a service user in SonarCloud (which would require a user in GitHub for example), and to restrict that user’s permissions to just create project & analyze project.
Since SonarCloud does not have project-specific tokens ( Project scoped analysis tokens for SonarCloud ) of course this means that any token can analyze any project.
About 2 years later, and it seems that this is still something that has not been addressed by SonarCloud. This is causing unnecessary interruptions and support overhead.
- Returned error messages are misleading and do not suggest that the issue is related to expired/invalid token
- Tokens being tied to the user who set up the project is not ideal and poses security concerns especially when user is an admin user. Project analysis tokens should be scoped to project analysis only. Even if we create a service account to mitigate the risk of tokens being revoked when user leaves the org, tokens created by that user seem to be authorized to analyze any project (not project-scoped) and probably have permissions beyond just project analysis.