We are relatively new to SonarQube, and I am struggling a bit and looking for some help and guidance.
We are using SonarQube Server - Developer Version v10.7 (96327)
Before I go into the details, I will give a brief breakdown of how we are currently set up
Our SonarQube Server is installed in an Azure Container Instance
Our Source code is all hosted in GitHub repositories
We do our builds and releases using Azure DevOps pipelines - 1 pipeline per solution
90% of our current codebase is .NET 8
Our application structure is quite monolithic with a lot of shared assemblies and dependencies (this will be changing later next year)
All 50 of our .NET solutions (.sln) are in one single root folder
All .csproj and code files are in a sub folder off where the solution files are located
We use GitFlow having Develop & Release branches off Master
I set up my initial project in SonarQube using GitHub actions
The problem that I am having is how to scan all of the 50 solutions when anyone generates a Pull Request into our release or master branches.
I just do not know the correct way to deal with this.
On the first analysis, I got an error, so had to specify a solution file in the dotnet build element of the build.yml file, and that appeared to work OK.
Also, because I have done this initial run on just one solution, does that mean that my baseline has now been set and everything after that will be seen as an incremental change. If so, is it possible to revert this, so that when I do have a solution to the above, I can rerun the analysis for my baseline.
For any given PR, you want all 50 solutions analyzed?
Generally, the way it works is 1 build → 1 analysis → 1 project in SonarQube Server
I’m not deeply familiar with .NET, but my understanding is that each solution is a different build, so that would be 50 different analyses. For one PR that seems like… a lot. And it will likely take a long time. Is that really acceptable in your context?
Thank you very much indeed for your reply and for the welcome. Very much appreciated…
So, each of our solutions has a main project. It does have some of it’s own specific assemblies, but the majority of the other projects (assemblies) are shared with other solutions. For example, we have a data assembly that we use to access our database, and that is of course used by multiple different applications, all of which access the database.
We are in the unfortunately position of having the legacy of a monolithic architecture / design, which we are in the process of moving away from, but this is a 12-24 month goal.
The problem we have is that we cannot easily tie a particular PR back to a specific solution, as the change could well be in one of the shared assemblies, and therefore affect multiple solutions.
If the assessment per solution is the only way we can go, we would probably have to tie the assessment into the build of the solution by the devops pipeline as oppose to doing it on the PR, which just feels a bit backward.
I genuinely cant think of any other way to deal with it.
For .NET, an analysis per build is the only way you can go. That’s because much of the analysis actually runs during the build. So… how are your solutions built? All in one go? Or individually?
Hi Ann, We build them one at a time using Azure DevOps build pipelines. These happen overnight on each of our environments, i.e. Development, UAT, PreProd and QA meaning we are essentially running 200 build pipelines every night during the week to ensure that all of our environments have up to date builds.
A lot of our issues are down to the monolithic nature of our application architecture, and that we are unable to do CI/CD, which as I mentioned previously we are moving are way towards, but it is by no means a quick process and expected to take up to two years to complete.
If we went down the rout of doing this on build, does this mean that this would fire off 200 assessments in SonarQube.
Is it that you can’t pin the PR to the specific solution that needs to be re-built / analyzed, or that you can’t accurately map the cascade of other projects that also need to be re-built/analyzed?
Because if it’s the latter, maybe you could limit the PR analysis to the component(s) directly affected & rely on the nightly analysis to make sure the cascade is okay?
I am not aware of any way to link a PR to a solution in GitHub unfortunately.
I am really struggling to identify a solution that is going to work for us here, and am beginning to doubt that our purchase of SonarQube is going to support what we are trying to achieve
I was hoping there was some organization within your monorepo that would put code files in a directory with their .sln files. Without that… Yeah, I’m at a bit of a loss too.
In the short-term, it doesn’t look like you’ll be able to analyze PRs (with reasonable time/effort) but your nightly runs are still valuable. And as you begin to re-organize your code, PR analysis will become more and more feasible.
