Sonarcloud-github-action publishes branch analysis to main and not the current branch

We have setup a new private repository to use GH actions and the main branch and PRs are reporting properly after following the official instructions here: GitHub - SonarSource/sonarcloud-github-action: Integrate SonarCloud code analysis to GitHub Actions

We do want to run the analysis on long lived branches and we have added the branch pattern accordingly, unfortunately when we trigger the analysis of a long lived branch (we use workflow_dispatch, so we only analyze on demand), the report is then published to the main branch in the corresponding SonarCloud project.

We usually run the sonar scanner in a different CI system where we have logic to explicitly set these several parameters to pass to the scanner.

For PR analysis:

  • sonar.pullrequest.key
  • sonar.pullrequest.base
  • sonar.pullrequest.branch
  • sonar.scm.revision

For branches:

  • sonar.branch.name

As a workaround we have this step in our GH workflow right after we checkout:

    - name: Extend environment for test reports
      if: <custom condition to decide if we want to run the sonar scanner>
      run: |
        echo "ENABLE_TEST_REPORTS=true" >> $GITHUB_ENV
        echo "REPOSITORY_NAME=$(cut -d/ -f2 <<< ${GITHUB_REPOSITORY})" >> $GITHUB_ENV
        . .github/workflows/set_sonar_env.sh

Then for the scanner:

    - name: SonarCloud Scan
      if: ${{ env.ENABLE_TEST_REPORTS == 'true' }}
      uses: SonarSource/sonarcloud-github-action@v2
      timeout-minutes: 5
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SONAR_ORGANIZATION: ${{ github.repository_owner }}
        SONAR_PROJECT_KEY: "${{ github.repository_owner }}_${{ env.REPOSITORY_NAME }}"
        SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

With set_sonar_env.sh:

#!/bin/bash

# This script will set the sonar properties so that branch analysis will not
# default on reporting only to the main branch.
# This writes the key/value pairs to the $GITHUB_ENV file which makes them
# available to the next steps in the workflow.

sonar_variables=(
    SONAR_PR_BASE
    # SONAR_PR_BRANCH
    SONAR_PR_HASH
    SONAR_PR_KEY
    SONAR_BRANCH
)

if [[ $GITHUB_BASE_REF ]]; then
    # Variables for PR analysis.

    # The target branch of the PR, e.g.: 'main'.
    export SONAR_PR_BASE="${GITHUB_BASE_REF}"

    # The branch of the PR, e.g.: 'user/bob/fixes'.
    # export SONAR_PR_BRANCH=???

    # For PRs the head of the target branch before the local merge is what we
    # are looking for.
    common_hash="$(git log 'HEAD@{1}' -1 -q | head -1 | cut -f 2 -d' ')"
    export SONAR_PR_HASH="${common_hash}"

    # For PRs GITHUB_REF_NAME is '<pr_number>/merge'
    pr_key="$(cut -d/ -f3 <<< "${GITHUB_REF_NAME}")"
    export SONAR_PR_KEY="${pr_key}"
else
    # Variable for branch analysis.
    export SONAR_BRANCH="${GITHUB_REF_NAME}"
fi

# Make the variables available to the next steps in the workflow.
for var in "${sonar_variables[@]}"; do
    echo "${var}=${!var}"
    echo "${var}=${!var}" >> "${GITHUB_ENV}"
done

I was expecting sonarcloud-github-action to be able to map to the correct branch out of the box and not need to do this additional work, which would probably be very difficult to figure out for folks that have no prior knowledge about this additional settings.

Note that the above is a partial solution as it breaks PR analysis with ERROR: Parameter 'sonar.pullrequest.key' is mandatory for a pull request analysis.

I don’t understand why we don’t autoconfigure branch analysis if the event is workflow_dispatch. I’ve flagged this for review.

I was able to simplify the logic by doing just setting sonar.branch.name explicitly when not on a PR:
sonar-project.properties:

sonar.branch.name = ${env.SONAR_BRANCH}

Then in a shell step of the workflow yaml:

        if [[ ! $GITHUB_BASE_REF ]]; then
          # GITHUB_BASE_REF is only set for PRs, we are on a branch.
          echo "SONAR_BRANCH=${GITHUB_REF_NAME}" >> $GITHUB_ENV
        fi

This way the sonar.branch.name is the only parameter to set and only set if we are not on a pull request analysis. Now everything is working well.

Hi @sodul
Thanks for reporting this, we will look into how feasible to implement a solution and will get back to you. In the meantime please apply the workaround.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.