Suggestions on how to perform analysis on a long-lived branch

SonarQube Cloud
1
  • ALM used (GitHub, Bitbucket Cloud, Azure DevOps): GitHub
  • CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI): CircleCI
  • Scanner command used when applicable (private details masked): sonarcloud/scan
  • Languages of the repository: python
  • Only if the SonarCloud project is public, the URL
  • And if you need help with pull request decoration, then the URL to the PR too

Hello,

I am seeking some clarification regarding branch analysis in SonarCloud. Currently, I have the “master” branch set as my main branch and a secondary branch, “preprod,” configured as another long-lived branch. I have set up a workflow in CircleCI to execute the sonarcloud/scan command (provided by the sonarsource/sonarcloud orb), whenever changes are merged into the “preprod” branch.

This is how the circle ci workflow looks like:

preprod-quality-after-merge:
    when:
      equal: [preprod, << pipeline.git.branch >>]
    jobs:
      - tests-with-coverage:
          context: private-secrets
      - sonar-static-analysis-coverage:
          context: SonarCloud
          requires:
            - tests-with-coverage

and the sonar-static-analysis-coverage job looking like this:

sonar-static-analysis-coverage:
    executor: base
    resource_class: medium
    steps:
      - attach_workspace:
          at: /tmp
      - checkout_repository
      - sonarcloud/scan

Could you please guide me on how to configure the analysis results to use “preprod” as the reference branch instead of the “master” branch, still keeping master as the “MAIN” one in sonar cloud?

Thank you for your assistance.
LA

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

2

I do not have any experience with CircleCI, we use Jenkins and a little bit of GH actions.

When performing a PR Sonar need to be passed the information that this is actually a PR and what the target branch is.

To do that on Jenkins we use the GitHub plugin and it will feed several environment variables that we then use to call sonar-scanner.

if [[ $CHANGE_ID ]]; then
    # 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' ')"
    echo "Common hash: ${common_hash}"
    sonar_args=(
        "-Dsonar.pullrequest.key=${CHANGE_ID}"
        "-Dsonar.pullrequest.base=${CHANGE_TARGET}"
        "-Dsonar.pullrequest.branch=${CHANGE_BRANCH}"
        "-Dsonar.scm.revision=${common_hash}"
    )
else
    branch="${GIT_BRANCH#origin/}"
    sonar_args=("-Dsonar.branch.name=$branch")
fi

We add more options then call sonar-scanner "${sonar_args[@]}".

When GitHub is notifying CircleCI that a PR needs to run it should already pass the target branch (CHANGE_TARGET in the example above). I would assume that the sonarcloud/scan is supposed to do something similar when feeding the parameters to the sonar-scanner process.