SonarCloud github action not evaluating PR properly when using pull_request_target

SonarQube Cloud
1
  • ALM used: GITHUB
  • CI system used: Github Actions
  • Languages of the repository: Golang

Hello there. I hope everyone is doing great!

I am having a small issue using SonarCloud Github Actions.

I am using Github Actions, and triggering SonarCloud Scan for PRs. Which works really well, if the trigger used to start the action is pull_request.
For some reasons, I have to use pull_request_target instead, which is bringing some problems.
SonarCloud Actions just doesn’t understand that it refers to a Pull Request, and applies the scan for the target branch.

I’ve tried to use something like

 - uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: refs/pull/${{github.event.pull_request.number}}/merge

      - uses: actions/download-artifact@v3 ## downloads all artifacts

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

During the checkout process I check out the PR ref, but still doesn’t work.

My question is the following: is there a way to instruct SonarCloud Action to inspect a specific PR?

Or is there any better way to handle this? Assuming I have to use pull_request_target.

Thanks in advance

2

Just adding more information

This is a short of my Github Action now.
I could make it work and reference the PR using sonar.pullrequest.key=${{github.event.pull_request.number}}

But this brought me another problem: SonarCloud doesn’t report back status to github.
I am restricting my PRs to only be merged when SonarCloud gate is fine, so I need SonarCloud reporting back. But for some reason, the combination of pull_request_target with SonarCloud action, even referencing the PR, is not working.

name: Quality Gate
on:
  pull_request_target:
    types: [opened,reopened,synchronize]
  push:
    branches:
      - main
      - dev
  workflow_dispatch:
    
jobs:
  matrix:
    runs-on: ubuntu-latest
    outputs:
      matrix: ${{ steps.set-matrix.outputs.matrix }}
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: refs/pull/${{github.event.pull_request.number}}/merge
          
      - id: set-matrix
        run: |
          TASKS=$(echo $(cat .github/workflows/matrix.json) | sed 's/ //g' )
          echo "matrix=$TASKS" >> $GITHUB_OUTPUT

  scan:
    needs: matrix
    env:
    strategy:
      matrix:
        service: ${{fromJson(needs.matrix.outputs.matrix)}}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}

      - uses: actions/setup-go@v4
        with:
          go-version: '1.21.3'

      - name: run tests and generate coverage report
        run: |
          make tests service=${{ matrix.service }}

      - name: Save coverage report
        if: always()
        uses: actions/upload-artifact@v3
        with:
          name: ${{ matrix.service }}-coverage
          path: |
            ./internal/services/${{ matrix.service }}/coverage.out
          retention-days: 1

  gosec-sonarqube:
    runs-on: ubuntu-latest
    needs: [scan]
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: refs/pull/${{github.event.pull_request.number}}/merge

      - uses: actions/download-artifact@v3 ## downloads all artifacts

      - name: Global SonarCloud Scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GO_MODULES_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          args: >
            -Dsonar.pullrequest.key=${{github.event.pull_request.number}}
3

Hi,

I suppose your difficulty here is down to the fact that those two triggers have different properties. Note the difference in the SHA and ref between pull_request_target and pull_request.

Since you’re not going the anticipated route, you’ll need to build all of it from scratch. The docs can help with analysis. For Quality Gate status, take a look at the sonar.qualitygate.wait property, as discussed here.

Would you mind explaining why you need to use pull_request_target rather than pull_request?

 
Thx,
Ann

4

Hi @ganncamp , thanks for the response.

We have some steps during our CI/CD process which commits with [skip ci] message.
In our case, makes sense to keep that way, so we can skip some workflows.

But we don’t want to skip Sonar workflow.

It forces us to use pull_request_target, as mentioned here: Skipping workflow runs - GitHub Docs

I’ve tried to use Other CIs | SonarCloud Docs. What I’ve faced is the following.

image
image1140×104 14.6 KB

image
image2176×796 81.3 KB

image
image1944×104 14.1 KB

The comment is added as it should on the PR. But it keeps blocked “Waiting for status to be reported”.

However, if I go to my other PR

image
image1232×104 15.5 KB

The status is reported there

image
image1844×104 16.7 KB

So the PR (test-sonar → dev) is running the validation, and Sonar is commenting on this PR as expected. But it keeps blocked waiting for status, which actually is reported to dev -> main PR (even though this PR doesn’t run Sonar validation).

5

Hi,

You’re saying the Quality Gate status is reported in the wrong place & the right place is stuck waiting for a status update that never comes?

Again, this is likely because the wrong envvars are being picked up because an unexpected trigger is used. We haven’t made any effort to document what it is you’ll need to override because… there was no anticipation of your alternate route, and it’s just supposed to work.

Sorry, but I don’t think I can be much more help.

 
Ann

6

Gotcha. Thanks for the feedback.

1 Like
7

Hi @ganncamp

Sorry to bother you.

Just a quick question: who is responsible to report back to PR the status check? I was checking the SonarCloud action and it doesn’t seem to be there.

8

Hi,

It’s on SonarCloud to report the status back. And it’s doing it, just in the wrong place (because it got the wrong information about where to report).

 
HTH,
Ann

9

Which information SonarCloud uses to report back?

I will try to handle this on my side, if possible.

10

Hi,

As I said,

 
Ann