Long living branches pattern does not work anymore

Hello,

for some reason all analysis of our release branches now appear as short lived branchs of the main branch. Checking the background tasks it seems to stopped working after June, 28.

We use VSTS with the SonarCloud build task. Our git branches are named main, develop, release/1805, release/1807, etc. The long living branches pattern is defined as (master|develop|release\/).* and hasn’t changed recently.

The log from our latest build on branch release/1805 contains this entry:
2018-07-05T08:37:31.6320360Z INFO: Branch name: 1805, type: short living

In a previous build the log contained this entry:
2018-06-28T18:55:24.8292473Z INFO: Branch name: release/1805, type: long living

Please let me know if you need more information.

Regards,
Tobias

1 Like

Hi Tobias

I just checked and it worked correctly, given the exact same pattern as you:

You might be missing one important point: once a branch is created, it remains short-lived or long-lived for its whole time life. This pattern is used only when creating a branch for the first time.

1 Like

Hello Fabrice,

the strange thing is release/1801, release/1803 and release/1805 already exist as long living branches, but updates stopped after last friday. In addition to that I now have branches 1801, 1803, 1805 and 1807 as short living branches under the main branch.

Our git branch release/1807 was created earlier this week and analysis is performed with the same build definition we use for all the other release branches. It was created as a short living branch in SonarCloud right from the start.

I deleted all those short living branches for now and check if they get recreated.

After I removed the short living branches, our git branch release/1805 was created as short living branch 1805 again last night. Although release/1805 already exists as a long living branch in SonarCloud and the pattern should have matched.

The same applies to the git branch release/1807, except that I haven’t been able to create a long living branch in SonarCloud yet.

Something’s definitely not right. Any ideas on what I can check or change next?

EDIT: I found something in our log files which might be related to the problem I am facing. The VSTS build tasks for SonarCloud got updated recently.

Last working analysis:

  • Prepare Analysis Configuration v1.3.0
  • Run Code Analysis v1.3.0

First ‘failing’ analysis:

  • Prepare Analysis Configuration v1.3.1
  • Run Code Analysis v1.3.0

Regards,
Tobias

1 Like

I’m still unable to get SonarCloud to recognize our release branches correctly. I triggered another build from VSTS for the release/1805 branch, this time with system.debug = true to get some additional debug information.

This piece from the Prepare Analysis Configuration step looks interesting.

##[debug]Build.Repository.Provider=TfsGit
##[debug]Build.SourceBranch=refs/heads/release/1805
##[debug]Default branch of this repository is 'refs/heads/master'
##[debug]Build.SourceBranchName=1805

Having a look at the last commits on the sonar-scanner-vsts repo I found this:

let isDefaultBranch = true;

if (provider === 'TfsGit') {
    isDefaultBranch = currentBranch === (await getDefaultBranch(collectionUrl));
}

if (!isDefaultBranch) {
    props['sonar.branch.name'] = tl.getVariable('Build.SourceBranchName');
}

Source: https://github.com/SonarSource/sonar-scanner-vsts/commit/7106f4914fe2c5aeaa03db38c6e882a1b1c3177a

Please correct me if I’m wrong but your previous version used Build.SourceBranch and truncated the refs/heads/ part to get the source branch name instead of simply using Build.SourceBranchName which only keeps the last component of the ‘path’.

Regards,
Tobias

1 Like

Hi Tobias,

You’re right, I changed the implementation in the latest release, to rely on the Build.SourceBranchName variable, which seems to me less fragile than manually assuming I should truncate the ‘refs/heads’ prefix.

The fact if contains only the last string after last ‘/’ looks like a bug to me.

I will check with Microsoft if this is a known bug on VSTS side.

1 Like

Hi Julien,

it’s not a bug: https://docs.microsoft.com/en-us/vsts/pipelines/build/variables?view=vsts&tabs=batch#buildsourcebranchname

I had some trouble with that variable before when I used it in one of my build definitions and it behaved differently from what I expected.

Regards,
Tobias

2 Likes

OK, waiting for Microsoft opinion on this, we will revert to the previous state:
https://jira.sonarsource.com/browse/VSTS-165

Thanks for reporting this.

2 Likes

Great,

do you have an ETA when the fixed version will be available in the Visual Studio Marketplace?

Regards,
Tobias

I just deployed version 1.3.2 of the prepare task. Please confirm that it solves your problem.

Looks good!

The missing release branch was finally created and the existing release branches were updated again.

Thanks,
Tobias

1 Like

Thanks Tobias for the confirmation.