Azure Devops and SonarCloud tokens management

What would be a good practice to manage the tokens used in Azure Devops and SonarCloud to set the connection between the 2 platforms ?
Today, we use project token, generated on SonarCloud when starting the analysis. This token is actually linked to the user profile.
This token is used on Azure Devops Service Connexion settings to create the SeonarCloud Connection for this specific project.

At the end, we have many ServiceConnections in the different Azure Devops projects, and each has his own tokens for the different repos (applications)

Also, in SonarCloud, on the PullRequest tab settings of the project, we include the PAT generated by Azure Devops on the User profile.

The question is : How are we going to keep it maintainable on the long run ? That seems to be a lot of tokens used on different users in different places.

Anyone coud share his experience on this ? Thanks a lot.

Olivier

Hey there.

Happy to read a thread where someone wants to manage fewer tokens rather than more in the name of security. :smiley:

We have an old Community Guide about Microsoft’s guidance for sharing connections across projects in an organization.

I would hope that almost 2 years on, this is available to all users. I would suggest looking at the Microsoft documentation linked and see what’s available in your context.

In fact, it’s an oddity that you can set this at the project-level at all (this is not how it works for any other DevOps Platform that SonarCloud integrates with). We’d actually rather that users not use this at all and instead have a single token configured under the organization-level Administration > Organization settings > Azure DevOps connectivity management.

I’ll refer to this documentation on Getting Started with Azure DevOps (that I’m actually really thrilled exists, as I’m only seeing it for the first time today).

Location of Personal Access Tokens in SonarCloud

When you set up your connection to Azure DevOps as described here, your Azure DevOps organization is bound to SonarCloud and the PAT from the Azure organization is registered at the SonarCloud organization level (not at the SonarCloud project level). If you later need to update the value of this token you can find it under Your Organization > Administration > Organization Settings > Azure DevOps connectivity management.

If you earlier set up an Azure DevOps project manually (not creating a bound organization) you may have registered the PAT at the SonarCloud project level (not the organization level) by filling the field under Your Organization > Your Project > Administration > General Settings > Integration with Azure DevOps Services.

Entering the PAT at the organization vs the project level in SonarCloud can lead to differing behavior. We recommend that you follow the tutorial to create a bound organization and make sure that the PAT is entered only at the organization level, not at the project level. The project-level field should be left blank.

I hope this helps.

Hey,

thanks a lot for the feedback. I’ll check if the option to share the token across projects applies.
That would definitely help.

Indeed, we had to create projects manually in SonarCloud for the reason we are in a monorepo setup.
4 different apps are managed in a single git repo. Not the best design for the devops guy trying to stick with the gitflow, but that’s how it is. will improve on the next project.

regards,

Olivier

Just to make sure I understand – what was the reason to create manual projects because it was a monorepo? Monorepos are supported for Azure DevOps.

Hi, yes you’re correct. Monorepo is supported. Maybe the creation of the projects was not manual, not sure anymore. I need to ask the administrator.
Now it’s working fine, analysis are ok and triggered on each branch push, PR creation and completion.
thanks for your help.

Olivier

1 Like

Thanks for the follow-up!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.