Long lived branches relative to master

  • ALM used: GitHub
  • CI system used: BuildKite
  • Scanner command used when applicable (private details masked): not applicable I think
  • Languages of the repository: C
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting): not an error, question about behavior
  • Steps to reproduce: none
  • Potential workaround: dunno!

Hello, my question feels a little hard to articulate but it concerns long-lived branches.

Let me start by describing what I would like to have happen, and then describe what I see.

We have a master branch but also very many LTS branches.

We would like the scans of the LTS branches to:

  1. live forever (because we need the results as proof for our certification efforts)
  2. be relative to master, not act as independent baselines

Adding the appropriate regex to the long-lived branch pattern takes care of point one, but not point two.

After the first scan of this type of the LTS branch it is confusing to users that the quality gate is not computed and, after doing a rescan, the quality gate comes back as perfect because, relative to itself, there were no changes.

What we would like, I think, is for the scan results of the LTS branch, the quality gate, to be relative to the most recent common ancestor between the branch and master, really as if it was a “short-lived” branch that just never got deleted.

I have just now noticed this in the documentation though:

If sonar.branch.name is a long-lived branch B, then sonar.branch.target T is the reference branch of B. This means that issues from T will be copied to B on the first analysis of B. See Issue synchronization, below.

That sounds helpful and I’ll give that a try, but I’m curious if my use case makes sense to a SonarCloud dev.



It’s not clear to me what your expectation is.

First, Quality Gates default to covering only New Code. As you describe, there’s nothing “new” in a branch that’s simply been reanalyzed without changes.

What is it that you’re expecting to have show up in the Quality Gate of your LTS branches?

When do your LTS branches fork off main? I would expect that initial fork-point to be the initial analysis, let’s call that sonar.projectVersion=0, and the next analysis would be when the first change is made to the branch. sonar.projectVersoin=1 starts there. Then, using the previousVersion definition for New Code, you naturally get a New Code / Quality Gate that covers the changes since your LTS branch forked from main.

Does that make sense?



Thanks for the response.

As simply put as I can, we want long-lived branches to look just like PRs or short-lived feature branches into main, except they don’t get deleted.

I think what you wrote makes sense, but for us LTS branches represent tagged releases to customers and they may never receive any follow-up commits to create a quality gate, and we’re more interested in presenting results relative to main than to the LTS branch itself.

I’ll sync with my team again and try to better articulate things.

Thanks again!


Hi JimS,

So… What are you expecting to see here? I can only guess you want issues fixed in main but not in lts1 to… show up… as “new”…? Or… something…?

As a reminder, the typical workflow is

code -> commit/push/etc -> ci checkout -> build -> anlayze

With no code, there’s never any reason to get to analyze.