Why not scan all branches?

  • ALM used: GitHub
  • CI system used: Jenkins
  • Scanner command used: sonar-scaner
  • Languages of the repository: Python and C/C++

I’m new to Sonar. By demand of engineering management we are implementing Sonar across all of our main repositories. It seems like the default is to only have Sonar run on the main branch. I don’t understand this thinking. Why not run it on all branches so that engineers see early and see often what is going on? If we wait until they want to pull/merge then we’ve waited too long - they are not going to be interested in going up and cleaning anything but the biggest of problems.

Obviously a lot of smart people have put a lot of thought into this so I’m wanting to understand what I’m missing. Why wait until the last minute to surprise developers with Sonar scan findings? Why not just scan all branches all the time?

Thanks -

Hey there.

It’s an interesting question – and I don’t think there’s a perfect answer. I see the benefits of both approaches.

Here is some of my thinking behind it:

  • Running analysis on each push of each branch consumes build resources, which may or may not be okay in your environment. Lots of SonarCloud users are running on hosted build environments with limited build minutes.
  • Developers can use SonarLint to catch issues as they code. This is a free IDE extension that integrates with SonarCloud, and it’s quicker than running a branch analysis.
  • Pull Request Analysis allows developers to get results without leaving their DevOps platform as a result of Pull Request Decoration.

And, all of that said, if you feel it’s more beneficial for branch analysis to run on each commit of each branch… nothing stops you from configuring it that way! It’s common to see Sonar users analyze both branches and pull requests.

I think this depends, partly, on the size of changesets your developers are introducing (more changes, more issues).

And, if you block the merge of a pull request until the Quality Gate is green (which is what we encourage), you start to nudge developers towards better habits around clean code (using SonarLint, rasing a pull request earlier for feedback from Sonar and from peers)

If you haven’t had a solution for Clean Code in your enterprise before, you might not know how they’ll react! We believe that across the board, developers want to deliver good code, as long as they have the right tools.