Scanner command: Prepare Analysis task during build (version 3.*), integrated with .NET
Languages: C#, HTML, CSS, JS
Hi, I have so far used an on-prem SonarQube server for many years, and this is one of my first projects in SonarQube Cloud. With this project, I did not set up the long-running branches pattern correctly before starting my scans, which resulted in my “dev” branch becoming a short-lived branch after the first scan. So I did what I’ve done many times with the on-prem product to turn a short-lived branch into a long-running branch:
Update the long-running branches pattern in the project (in this case, to “dev|main”)
Delete the branch from SonarQube
Re-scan the branch in Azure DevOps
It shows up again in SonarQube, only now as a long-running branch.
I know that this erases the history of the branch in SonarQube, but that was fine. Unfortunately, step 4. never happened, even after several commits, PRs, and scans for this branch. It’s now gone, and will not come back as either a short-lived or long-running branch in SonarQube Cloud. All other branches I scan (new and old) show up just fine.
This is a private repo, with a legacy paid plan for up to 100k LOC.
When the analysis is submitted by the scanner for this branch, where does it say the analysis will end up?
09:56:24.371 INFO Branch name: release-6.7, type: long-lived
...
09:56:25.726 INFO ANALYSIS SUCCESSFUL, you can find the results at: https://sonarcloud.io/dashboard?id=colin-sonarsource_testproj&branch=release-6.7
Thanks @Colin, this sent me down the right path, albeit an unexpected one.
Right around the time when I tried to make dev a long-running branch, I also changed the dev branch in Azure DevOps to be the Default branch. This makes it a little easier to create PRs, as it’ll be the default merge target for any feature branches. As it turns out, when the code analysis task scans code for the Default branch, it will omit the branch name when sending the results to SonarQube, so my scans for the dev branch landed in the one that’s labelled as the Main branch in SonarQube, in this case main. I don’t remember this ever being the case in the on-prem product - has this changed within the last year or so?
Either way, here’s my workaround for now:
Rename the main branch in SonarQube to dev to match what’s actually happening
Run another build for the main branch in Azure DevOps
Result: SonarQube creates a new main branch and now shows both dev and main as long-running branches. dev is still labelled as the Main branch in SonarQube, which is not ideal, but that’ll have to do for now.
Is this expected behaviour, or is there something I’m missing that would allow me to have dev as the Default branch in Azure DevOps, but main as the Main branch in SonarQube?
What’s happening behind the scenes is that the Extension for Azure DevOps checks to see if the branch being analyzed is the default branch, and if that’s the case it does not send sonar.branch.name.
This has been the behavior—as far as I can recall—forever. This is all done to ensure that sonar.branch.name isn’t passed to editions of SonarQube that don’t support branch analysis.
I don’t think this is a common use case, but I think you could configure sonar.branch.name=$(Build.SourceBranch) in your SonarQubePrepare step to force the branch name to always be sent.
However, you’d have to sort out a way to not pass sonar.branch.name at all if you’re running in a PR context.
Interesting - that explains things. I had always explicitly set the sonar.branch.name in my on-prem setup, and only recently added PR decoration with the switch to cloud.
I may just set up a separate build process that’s used for PRs, where I don’t set the branch explicitly. That would also be a way to save some storage, as I could then discard the build artifact at the end instead of publishing it for a release that never happens.