Best approach for managing sonar tokens

Hello everyone!

Let me ask something related to sonar tokens automatically expiring after 60 days of inactivity.

Our current approach for analysis execution is using a different sonar token for each project. Also when grouping projects into portfolios, every project gets a unique token.

Now this approach shows some drawbacks with the newly realesed automatic expiration of sonar tokens after 60 days of inactivity.

In our enterprise, development teams, the team responsible for administering SonarQube and the one responsible for DevOps pipelines are different teams, so replacing expired tokens is not straightforward…

My question is: should we reuse the same token for all projects belonging to the same portfolio? Is that feasible? Is that secure? Should we use a single sonar token for all analysis executions across an organization?

Please, advice on how we should manage analyses execution tokens in order to minimize the probability of letting them expire due to inactivity.

Thank you in advance!

Hi,

Sorry, but I need to start with a question of my own.

Tokens don’t expire after 60 days. They expire after 60 days of inactivity. How is it that your projects sit that long without reanalysis? As a best practice, you should be analyzing on every change. And to be clear, in case this is the issue, you can reanalyze the same 1k-LOC project 100 times and it counts against your license as… 1k LOC. You don’t use up your license by reanalyzing the same code over and over. You just make sure your code stays healthy. :wink:

So I would start here by re-examining why your tokens are able to expire.

But if it’s really the case that you have a bunch of projects sitting around that only get worked on once or twice a year, then it probably makes the most sense to unify them all under one token and hopefully among them they can keep the token alive.

 
HTH,
Ann

Hi @ganncamp,

thank you for your reply.

I’m aware that the expiration is after 60 days of inactivity and that repeated analyses does not impact LOC: we are analyzing the code every time th code is built and deployed.

We are not a software company: we use and integrate a lot of software, and also develop some, but it’s not our core business. As such, especially when microservice-based projects are involved, it happens that some repo gets updated infrequently when the project becomes very stable.

So, do you confirm it is safe to share a single token among different projects to avoid expiration by inactivity?

Hi,

We consider this standard practice.

 
HTH,
Ann

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