We have code analysis set to analyze our Master branch. We had code freeze and had not checked any other code into that branch since September 23rd. However, SonarCloud is still running analysis on the branch even though nothing is being checked into that branch and keeps reporting passing and failing scores. Why is this happening?
The analysis is always triggered by something external to SonarCloud (generally a trigger that comes from the SCM, but it can be also a periodic scheduling of the job in the CI)
Can you provide more details on your overall devops environment ?
I have a master branch which is a long-living branch and a development branch which the devs work off of. From that, they have feature branches to work concurrently. I’m using this pattern in Sonar. Long living branches pattern: (branch|master|dev|release).*
The devs create branches with “feature” or “fix” in the name so I have omitted those from the analysis. I only want to analyze the master and the dev branch for our security report and so that the devs can see what the analysis is before merging back to master.
Thanks for the additional details.
This does not change much the problem: I can only see 2 possible reasons for the scan to happen on a branch where there is no new code:
- Your CI tool is configured to trigger builds on a periodic basis even if no new code landed on the branch, a feature that’s available in many CIs.
If you are using SonarCloud autoscan feature, forget this case, scans are only triggered on commit (an no CI is really involved in the process)
- There are some files changed on the branch, but files that are not source code (eg a config file or whatever). This will trigger a build+scan (trigger on commit/push) but obviously SonarCloud will find not modified source code since the files that were changed are not source code
Can yo provide details on your CI set up ?
PS: This is not the subject of this thread but Why do you not scan feature or fix branches ? That would allow devs to find out (and fix) issues on these branches before merging on develop (shift left principle)
I work with Sean,
We found some of the issue. Our dev branch build did not have an explicit sonar.branch.name set, it supposed to figure it out automatically, but if we set it manually in our Azure Devops job the master branch statistics don’t get messed up.
This brings us to a 2nd issue, we didn’t have dev in the long lived branch pattern and it got created as a short lived branch feeding into master. So when we go look at the dev branch in SonarCloud we just get the short summary of what will happen when we merge into master. Our dev branch is going to be around forever and we would like to get the full report that we see in master available on dev. It would seem that we need to move dev to be a long lived branch, but once it’s created as short lived how do you fix it.
We don’t run Sonar on the feature branches until a PR is raised, there is a different PR build that does a quality gate. This was done to speed up builds at developers request, it isn’t that much of a savings, knocking a minute off of a 13 minute build, but our build times are creeping up.
Welcome to the community. The more the merrier
The decision whether a branch is short or long lived is taken only once at branch creation. After that, if you want to change the branch type you have no other way than deleting the branch and re-analyzing it with the other type.
This is not a big deal since it will re-generate all the issues and metrics. The only thing that you will lose is any manual change you may have made on issues of the branch such as marking as False Positive/Won’t Fix, changing issue severity or type, assigning to specific developers or adding comments.
Will be deleting and re-creating dev branch.
Thanks for the help!