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:
live forever (because we need the results as proof for our certification efforts)
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.
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.
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.