I am not explicitly using sonar.branch.name however, I have seen in another topic, that some of these actions (in that case it was Azure DevOps) automatically set the sonar.branch.name.
The dev branch is not the default branch, and as such, when the project is created upon its first scan, it shows Master (main branch) not analyzed and my-branch aka dev as having a scan result… but not nicely showing on the home-page of the project and this is the issue.
I’m trying to gauge whether this is the intended behaviour when using the scanner action from SonarSource. Do they intend for people to scan their develop and have it be also the default branch or, do they intend for people to scan the master too so the project dashboard has a nice visualization.
This is the expected behavior – SonarQube tries to mirror the DevOps platform so if it detects that your first analysis is not the default branch in GitHub, it won’t make it the main branch (and the main branch is what is shown first everywhere in the UI).
I think this makes sense (but I’ve also been using SonarQube for a long time), so that you know when you’re browsing a selection of projects on your SonarQube instance, you’re always getting the information from the default branch (not any branch that might have been the first scanned).
Does this make sense to you?
I’m also obliged to tell you that as a non-LTS version SonarQube v9.1 is EOL – an upgrade to v9.4 should be in your future.
Hi Thanks Colin, I’ll upgrade our image. We’re using the helm chart so that should be pretty easy.
this morning my colleague helped me out… he showed me that we just have to delete the named-branch w/ the scan results, then the master branch was there with no results… after it’s the only branch showing, we rename it to be the name of the incoming development branch and now that’s showing up as the ‘main branch’
later, scans of the main/master or other branch names should optimistically be visible but not be labeled the ‘main branch’