SonarCloud interprets closed PR as branch analysis

[ernstdehaan]

We use SonarCloud and use the Sonar Scanner in a GitHub Actions workflow. The workflow is configured in the main branch (develop) and triggers when a PR is merged into that branch.

Here’s the trigger we use:

on:
  pull_request:
    branches:
      - develop
    types: [closed]

…and this is the command we use (further down in the GitHub Actions workflow definition) to run the Sonar Scanner:

      - name: Sonar Scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

When this is run, then Sonar Scan interprets this as a Pull Request scan, as can be seen in the log out:

INFO: ANALYSIS SUCCESSFUL, you can find the results at: https://sonarcloud.io/dashboard?id=OUR_PROJECT_ID&pullRequest=812

However, I would like Sonar Scan to interpret this as a scan for the main branch instead. How can I instruct Sonar Scan accordingly?

I tried a couple of things already:

1. Changed the git checkout to explicitly check out the develop branch, rather than some other ref. No effect.
2. Passed a couple of additional arguments to the Sonar Scan: -Dsonar.branch.name= -Dsonar.pullrequest.branch= -Dsonar.pullrequest.key= -Dsonar.pullrequest.base= – also no effect.

Perhaps I need to pass a certain command line argument? Or perhaps I need to unset certain (GitHub-specific?) environment variables? Any suggestions would be appreciated…

( Note that I filed this as a bug since I would expect that a pull request closure is not considered to be the scan of a PR, but rather the scan of the target branch… )

[Colin]

Hey there.

Your current YAML suggests that pull requests targeting develop should be analyzed once they are closed, rather than analyzing the develop branch when new commits are added (via PR merge or direct commit)

In the case where you want to analyze the develop branch whenever there’s a commit, and PRs when they are opened (which I would assume you want, so you can catch issues before they get into your develop branch)… I would suggest a trigger closer to this:

name: Build
on:
  push:
    branches:
      - develop
  pull_request:
    types: [opened, synchronize, reopened]

[ernstdehaan]

Thanks for the suggestion @Colin , but the trigger is not the problem. This is exactly what we want to have as a trigger: scan as the PR is being merged to the develop branch.

The challenge I have is only that Sonar Scan interprets that as a PR scan, and not as a scan of the main branch.

[Colin]

That’s because the action is being triggered on something g happening to the pull request, not something happening to the target branch. The workflow, as configured, would also run if you didn’t merge the pull request (and just closed it because it was “bad”).

What are the envisioned negative effects of configuring the trigger on the develop branch? It would do exactly what you are describing as your goal!

[ernstdehaan]

There is some other script running in the workflow that determines the build version. It needs information about the PR that was being merged.

[Colin]

If you really want to, you should be able to pass -Dsonar.branch.name=develop which would stop the automatic configuration of Pull Request Analysis (if you have trouble doing this, feel free to show us the YAML where you try).

      - name: SonarCloud Scan
        uses: SonarSource/sonarcloud-github-action@master
        with:
          args: >
            -Dsonar.branch.name=develop
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Needed to get PR information, if any
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

[ernstdehaan]

@Colin : I have actually tried that, too (should have mentioned that in the original post). But then what happens is, it creates a new branch called “develop” under Branches, rather than considering this to be the “main branch.”

Then I tried setting that sonar.branch.name to an empty value, but that didn’t work either.

In the mean time I also tried something else: I set a number of environment variables to empty values:

      - name: Sonar Scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
          SONAR_TOKEN: "${{ secrets.SONAR_TOKEN }}"
          GITHUB_EVENT_NAME: "push"
          GITHUB_BASE_REF: ""
          GITHUB_HEAD_REF: ""

…however, that also didn’t work. Somehow it still detects that this is about a PR, as it’s printing:

INFO: Auto-configuring pull request 14

…and then later on it’s failing with this:

ERROR: Error during SonarScanner execution
ERROR: Could not find a default branch to fall back on.

So can I somehow instruct Sonar Scan to consider this to be a scan of the default branch?

[Colin]

You can rename your main branch in the project-level Branches page.

You would want to rename it to develop

[ernstdehaan]

Ah, understand; that’s helpful – this will get me a step further.

I do have two remaining questions though:

1. Can I get this to work on the initial scan of a repository? (looks like that is not possible)
2. Can I configure the long-lived branch name pattern declaratively, in my sonar-project.properties file or with a -Dsonar.something argument? (I cannot find it in the documentation)

[ernstdehaan]

@Colin : Indeed your suggestion (pass the sonar.branch.name parameter on the Sonar Scanner, and then rename the main branch in the SonarCloud UI) has resolved the issue for me. Thanks a lot!