Sonarqube 8.1 branch analysis, definition of new ?!

Hi,

playing with Sonarqube 8.1 Enterprise, happy to see there’s only one kind of branch now, but …

We use a quality gate with only ‘new’ conditions for our java legacy projects.
Using a simple Maven project with just one class for the tests.
First analysis of master branch gives quality gate OK, as this is the first analysis.
This was expected and works similar in our production instance with Sonarqube 7.9.1 Enterprise

Now i create some new branch foobar from master and put some sysout into code to provoke an issue.
But the analysis behaves exactly as the master branch, means the quality gate is OK !?

With Sonarqube 7.9.1 this would have been a short-lived branch with quality gate failed
because of 1 issue.
Put another sysout into code and do another scan for foobar branch => quality gate fails
because of the 1 new issue.

So it is possible to create a branch from master and put a lot of issues in it, but quality gate
will be always OK for the first branch analyis.
If the next analysis brings new issues the quality gate will fail.
But what about the issues from the first branch analysis ?!

When using another quality gate without ‘new’ conditions it works fine.
So how should that ever work with a quality gate using ‘new’ conditions ?
I thought the definition of new = the git changeset from branch master to branch foobar !?

Is it possible to change this behaviour ?
If not, this is a bug / showstopper IMO. Can’t update to Sonarqube 8.1, as this will not work for us.

Gilbert

2 Likes

Hi Gilbert,

The first analysis of a branch creates a new baseline for “new code”. Including the changes introduced in the analysis that is creating that branch is not trivial since branches no longer have a “target” with which they can be compared with.

However, we plan to revisit this and see if there is a simple way to include changes that in a typical setup with a CI, were probably done when the analysis was triggered.

If you were using short lived branches before, you might want to migrate them to P/Rs (since it means you had a target branch) where you will have the same behavior as before.

Hi,

going from short-lived, long-lived branch to a branch is a branch is a branch is great :love_you_gesture:
But the new behaviour prevents me updating from Sonarqube Enterprise 7.9.1 to 8.1 which is
quite annoying, as the problem with using sonar.branch.name in first analysis is fixed and PR
decoration for Azure Devops.

We have a lot of generic Jenkins pipelines, which simply use $BRANCH_NAME provided by
Jenkins as sonar.branch.name to activate the branching feature.
All is fine, also the PR workflows.

But now, the first analysis of every branch will result in ‘Quality gate passed’ - even if
introducing a bunch of issues when using a quality gate with ‘new’ conditions.
Only the second analysis will fail the quality gate, but the issues from initial branch analysis
will be ignored / get lost.

This doesn’t work with quality gates using the new conditons for legacy projects :frowning:
Your proposal with simulating a PR feels like a hack, it’s no clean solution.

The most simple way to fix this, is to bring back sonar.branch.target with master as default,
as simple as that.
In fact we use sonar.branch.target only for special cases, so it works almost always
using the default, means sonar.branch.target = master.

Gilbert

Hi,

in the meantime i did several tests with your workaround proposal and … it does not apply.
Created a feature request, hope it gets proper attention, as this will hit ALL customers
with Developer Edition and higher after updating to Sonarqube 8.1

(i know your official recommendation for Enterprise customers is to stay with LTS version,
but i’m sure you’re also interested in Enterprise customers living on the bleeding edge !?)

I have used the JGit api, have ideas and would like to help, but as this will be closed source,
it’s not possible to see the code or create PRs.

Gilbert

Hi @dmeneses.

I’ve run into the same issue as Gilbert. It was rather unexpected that branches do not behave as e.g. a git branch would (maybe it’s just bad naming).

Unfortunately, there is significant difference in the way that branches and pull requests work, which makes it impossible - at least for us - to switch to them. When doing a branch analysis, the entire source code in the referenced folder is considered (irregardless whether it is committed or not). With pull requests, only files found in the git history are considered.

Due to that, pull requests do not work to analyze the full project in these cases:

  • on-the-fly auto-generated code
  • pulling in (by tag or hash) another git repository into a sub-folder (e.g. using vcstool or using git submodules)

branch analysis works in all of these cases. I am not quite clear why this is handled differently to pull requests :frowning:

As a result, we can not use branch or pull request analysis to check our updates prior to integration. Do you have any recommendations? (We are using SonarQube Scanner 4.2.0.1873 and SonarQube server 8.1.0, sonar.scm.exclusions.disabled is set to true)

1 Like

I too am running into issues with this. In our current build process we have the branch name, but not the PR number, which appears to be a requirement to use the PR functionality in sonar. Previously with v7.9.1 the short lived branches seemed to handle the new code metrics fine, but now with v8.1 almost anything is passing our quality gate b/c our build isn’t triggered until a PR is submitted.

i would love it if anyone has a simple workaround I can put in place to have new code metrics handled the same as they were in v7.9 or always compared against master until I can revisit my build process to see if I can get the PR behavior working.

FYI - we ended up restoring our DB and rolling back to 7.9.2 in the meantime. I did find a potential solution to getting the PR ID into my build jobs that would perhaps let me use the PR functionality in 8.1 (https://mohamicorp.atlassian.net/wiki/spaces/DOC/pages/210305025/Sending+URL+Parameters+to+Jenkins), but after reviewing some of the other issues highlighted here I decided we may best stick with the branch functionality at this point, which means I’ll need to wait until something is done to address the “new code” issue.

This has affected us, as well.

In the ticket referenced in the release notes, there is the explicit assumption made that no one will build all branches. Unfortunately, this is exactly what we do as 1) we want our developers to have immediate feedback on their code before it enters the release process, and 2) we use BitBucket which has no concept of a draft PR. If we adopted the required PR workflow, since there is no “draft” functionality all of our reviewers would be inundated with untested PR notifications and our developers would be frustrated to start a release process only to run a test. Furthermore, our automation is driven in part by our issue tracking system, in that we prevent code changes without a ticket being referenced and in the correct status, and that we create PRs automatically by promoting the issue through the process. This is wholly incompatible with the new required workflow and would require significant changes to our tooling to adopt in any effective manner.

The ticket also said using a branch as a target is marked “out of scope”. I seriously hope that this meant for the 8.1 initial release and not for the feature itself as this is means we’ll likely be stuck on 8.0 for the foreseeable future.

Hi,

Is there already a concrete plan to tackle this problem ?

Gilbert

Hi,

Outside of the PR analysis, there’s indeed no real option that allow you to visualize the new code of a branch by comparing it to another branch. There’s no workaround to make branches behave the way short-lived branches were working and nothing that can really mimic the PR behavior without creating a PR.

We are aware that not everyone can use PR early in the workflow and, as Codey noticed, we’ve already thought about a way to visualize the new code as a changeset compared to a branch. Version 8.1 was not including it, but I confirm we do plan to make adjustments.

Hi Chris,

That’s good news.
But my stupid questions remains, why not simply bring back sonar.branch.target with
default = master ? You have the working code already, what are the cons of my proposal ?

Gilbert

2 Likes

I would also vote for bringing back that feature.
We can’t use the Git Integration with Pull Requests and etc. because of other limitations.
So we can use only properties like sonar.branch.name
Without that old sonar.branch.target a developer needs always to do a clean analyze build on his new branch, before he do any changes, which cost a lot of additional resources.

Hi Gilbert,
Using always master as the target might work for you, but a lot of users have different targets in their P/Rs and there is no way for their CI script to guess what will be the target of the P/R once it’s time to open one. That’s the reason why we wanted users to rely on draft P/Rs. Since these don’t exist in some ALMs, we’ll try to find a solution that can cover that case.

Hi @dmeneses

as i wrote

The legacy projects are nearly 30% of all our Sonarqube projects, only a fraction.
So it’s not always master - even legacy projects started using git flow, but in most cases
we didn’t bother setting sonar.branch.target as default is master, sufficient for most cases.
Also not all of our new ‘agile’ projects do use a PR workflow.

In the real world you’ll always have this mix of nearly 20 years old legacy projects with the
newer ones.
That’s my reason for the proposal = bring back sonar.branch.target , otherwise it won’t
work for all (real world!) scenarios.
I already signaled this will hit all users migrating to Sonarqube 8.1+
Sonarqube has to support all possible common workflows.
I’m still rather disappointed you’ve ignored this for the redesign of branches with SQ 8.1
This community forum is suited for discussions with the users !?

Sick of Corona blues,
Gilbert

@Chris @dmeneses

What would the workflow be here?

We use a feature branch strategy, so when multiple people are working on a piece of work, they create a “features/my-feature” branch.

As I understand it, as it stands, if someone did a PR into this branch, then ran branch analysis, it would not pick up any of the changed code?

So I have to configure PR analysis instead, which will fail as the target will not exist, correct? So i’ll require people to go run the static analysis build whenever they create a feature branch?

I found the ticket created to address the shortcomings of this feature. Given the impact this feature had to our workflows, some of us are very interested in updates and are getting frustrated at the perceived lack thereof. Hopefully this will help.

Much like @Rebse, we also have legacy projects that will not be migrating workflows as we do not have the resources to refactor all of them but we still must support them for our current customers. We also have projects that aren’t in any sort of ALM (old SVN based projects) so PR workflows would never work, which I hadn’t even considered until I read the ticket. @Chris, I’m glad you guys are considering this case as well.

1 Like

Hi @SinisterMinister ,

thanks for the link and maintaining this important thread!
Did not have much time to follow this forum with adequate attention due to personal and
professional circumstances.

And thanks to @Chris for creating this (overdue) ticket.
But now i’m quite disappointed again. Ticket has creation time 09/Mar/20, but nobody
tells us in this thread - even it’s of high significance for many and keeps us from updating !?
Does Sonarsource shy away from discussion with community ?! :thinking:

Hope you’re well,
Gilbert

I had the same feeling but I looked at the history and saw @Chris was actively still defining the ticket. Sounds like they’re still working through the scenarios and grooming the ticket.