Skip branch and pull request tags for Community Edition builds (TFS/VSTS)


(Emil) #1

We use the community edition of the SonarQube server, run on-premise. We have in the recent versions of the VSTS/TFS marketplace app run into a couple of issues regarding branch names and pull requests.

Versions used: VSTS task 4.3.2 and SonarQube 7.3

The issue:

  • When you detect other branch than master, you automatically add the tag. We are on the community edition and the branch plugin isn’t installed. Which leads to build failure
  • When you detect that it is a pull request you add several sonar.pullrequest.* properties. And since we have community edition that will fail the build.

Expected result:
The build will go on as usual and always overwrite the sonarqube analysis result, for any branch. This is how it always worked before.

Actual result:
The build is trying some non-community features and fails the build.

Example Solution
Here is an example on how it could be solved in your common/prepare-task.ts file. Skipping all the tagging if the edition isn’t a licensed one (e.g. community). But since I didn’t know how to get the SonarQube edition info from the vsts task I didn’t send a pull request.

async function populateBranchAndPrProps(props: { [key: string]: string }) {
  const collectionUrl = tl.getVariable('System.TeamFoundationCollectionUri');
  const prId = tl.getVariable('System.PullRequest.PullRequestId');
  const provider = tl.getVariable('Build.Repository.Provider');
+ const isLicensed = SomehowGetEditionFromSonarQubeAPI(endpoint) 
- if (prId) {
+ if (prId && isLicensed) { 
    props['sonar.pullrequest.key'] = prId;
    props['sonar.pullrequest.base'] = branchName(tl.getVariable('System.PullRequest.TargetBranch'));
    props['sonar.pullrequest.branch'] = branchName(
    if (provider === 'TfsGit') {
      props['sonar.pullrequest.provider'] = 'vsts';
      props['sonar.pullrequest.vsts.instanceUrl'] = collectionUrl;
      props['sonar.pullrequest.vsts.project'] = tl.getVariable('System.TeamProject');
      props['sonar.pullrequest.vsts.repository'] = tl.getVariable(REPO_NAME_VAR);
    } else if (provider === 'GitHub') {
      props['sonar.pullrequest.key'] = tl.getVariable('System.PullRequest.PullRequestNumber');
      props['sonar.pullrequest.provider'] = 'github';
      props['sonar.pullrequest.github.repository'] = tl.getVariable(REPO_NAME_VAR);
    } else {
      tl.warning(`Unsupported PR provider '${provider}'`);
      props['sonar.scanner.skip'] = 'true';
  } else {
    let isDefaultBranch = true;
    const currentBranch = tl.getVariable('Build.SourceBranch');
    if (provider === 'TfsGit') {
      isDefaultBranch = currentBranch === (await getDefaultBranch(collectionUrl));
    } else if (provider === 'Git' || provider === 'GitHub') {
      // TODO for GitHub we should get the default branch configured on the repo
      isDefaultBranch = currentBranch === 'refs/heads/master';
    } else if (provider === 'Bitbucket') {
      // TODO for Bitbucket Cloud we should get the main branch configured on the repo
      isDefaultBranch = currentBranch === 'master';
    } else if (provider === 'Svn') {
      isDefaultBranch = currentBranch === 'trunk';
-    if (!isDefaultBranch) { 
+    if (!isDefaultBranch && isLicensed) { 
      // VSTS-165 don't use Build.SourceBranchName
      props[''] = branchName(tl.getVariable('Build.SourceBranch'));

(Emil) #2

Has anyone looked at this? I want to update to the 4.4.1 version of the build task. But if this isn’t fixed it serves no point and I have to keep using my “modified” version

(G Ann Campbell) #3


You may find this thread helpful:


(Emil) #4

Hi Ann,

Well, not really since it says what I already know is true:

For Git if it’s anything else then refs/heads/master then it will set , resulting in a failure if Community Edition is in use.

That wasn’t the case with previous versions of SonarQube. I can switch to the 3.* version of the build task and it will work as expected, it will update the SQ results no matter which branch I build on. (And therefore not be as reliable since the # of issues is different from branch to branch)

Also, it worked in 4.2.*, only to stop working in 4.3.*. A bump in minor version should probably not be breaking? I would be fine if there was a major version release (5.*) that did have breaking changes, since then I could be on 4.* until we bought the licensed version. I can’t stay on 4.2.* in VSTS/TFS/AzureDevOps.

I understand that you need to have some exclusive features for the paid versions, but I don’t think you should take features away (even though you probably considered this a bug). Having branch support within SQ is reason enough to upgrade. The problem is that this has generated a lot of build management support within our company and a some negative thoughts against SQ, and it will be harder for me to convince management to buy a license.