I’m overseeing 300 SonarQube projects in an Enterprise Edition server that currently hosts over 5000 projects. In my area, we rely on project tags to find the diffrent subsets of projects we need to work with. We ask all of our teams to add a specific tag that identifies the project as belonging to our department, another tag to indicate that the project belongs to a specific team, and a third tag to indicate that a project is part of a particular area of our overall software suite.
The first ‘department’ tag makes it easy to list all our projects in the projects view and do things like sort them by last analysis date to identify projects that have not been scanned for a long time. The team tag enables a team to do the same things for just their projects or to group their projects into a portfolio. The product area tag we use to group products into portfolios for overall visibility and reporting.
This is works very well for us as long as people ensure the right tags are added. Do others manage sets of projects in different ways and what might the advantages might be of doing it that way instead?
When you started describing your scenario, my first though was portfolios. A lot of folks enforce a project key “naming” convention that automatically adds projects to the correct portfolio(s).
But what that doesn’t give you is that sort by last analysis, which I find interesting for governance purposes.
It sounds like you have a nice setup.
We have developed a service which uses the SonarQube API to maintain a portfolio hierarchy that reflects our organization. Data about projects, teams, tracks and streams are read from an internal service and used to keep the SonarQube portfolios updated. It works quite well.
Please share the solution you have developed.
Unfortunately I cannot share the solution, but I guess it would also be of limited use because it is very specific to our organization and infrastructure.
The solution is simply a batch job which (currently) runs every night. It collects data about our organization and project responsibilities from some internal services and uses the SonarQube API to create/delete/move portfolios and projects accordingly.
@MortenHindsholm out of interest, what is your batch job written in - powershell? bash? something else?
Have you found any libraries to simplfy interacting with the API or is it all “hand cranked” http calls?
I will soon need to do some data scraping from our Sonar prod instance and hoping to find some nice abstration over the API to help with that…
The job is written in Java and uses the Quarkus platform.
There is no fancy API abstraction, just standard HTTP calls using the Microprofile REST client.
But it definitely might make sense to put some effort into creating a nice abstraction because the API is not always very consistent.
Agreed, the API is neither consistent nor intuitive - I would prefer a more RESTful style API…or at least something that better models the object relationships and is more easily discoverable…