Sonarcloud stoped posting analysis report in Github PR but still posts them in the actions

I’ve just noticed that projects that are being analyzed automatically have the comments posted, but the projects that are being analyzed using github actions don’t

Hi @jtymoschuk

From what I see on our side the last comment pushed was on PR #47, June 9th (Timestamp: 2022-06-09T10:23:19.457+02:00). The last comment on PR #45 was on June 3rd.
Do you know if something changed on your configuration of GitHub Actions around that period, especially in the Action triggers or configuration?

Feel free to post here the configuration of your GitHub action expurged from the private details for further help.

The last change in the actions file was on 24.04.2022 so it’s not this configuration.
Here is the actions configuration

name: 'build-verify-analyze-job'
description: 'build job for feature'

inputs:
  PACKAGE_ACCESS_USERNAME:
    description: 'Github package credentials: user name'
    required: true
  PACKAGE_ACCESS_TOKEN:
    description: 'Github package credentials: access token'
    required: true
  SLACK_WEBHOOK_URL:
    description: 'slack webhook url'
    required: true
  SONAR_TOKEN:
    description: 'Token for integration with sonarcloud'
    required: true
  SONAR_PROJECT_KEY:
    description: 'Project identifier on sonarcloud'
    required: true
  JDK_VERSION:
    description: 'JDK version'
    required: true

outputs:
  container_image_tag: 
    description: "Number of files copied"
    value: ${{ steps.container_image_tag.outputs.value }} 

runs:
  using: 'composite'
  steps:
    - name: Set up JDK
      uses: actions/setup-java@v1
      with:
        java-version: ${{ inputs.JDK_VERSION }}

    - name: Cache SonarCloud packages
      uses: actions/cache@v2
      with:
        path: ~/.sonar/cache
        key: ${{ runner.os }}-sonar
        restore-keys: ${{ runner.os }}-sonar

    - name: Cache Maven packages
      uses: actions/cache@v2
      with:
        path: ~/.m2
        key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
        restore-keys: ${{ runner.os }}-m2

    - name: Test & Code Analysis
      if: ${{ always() }}
      env:
        GITHUB_USERNAME: ${{ inputs.PACKAGE_ACCESS_USERNAME }}
        GITHUB_TOKEN: ${{ inputs.PACKAGE_ACCESS_TOKEN }}
        SONAR_TOKEN: ${{ inputs.SONAR_TOKEN }}
      run: mvn clean install jacoco:report jacoco:report-integration jacoco:report-aggregate org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.dynamicAnalysis=reuseReports -Dsonar.projectKey=${{ inputs.SONAR_PROJECT_KEY }} --quiet --settings .github/settings.xml
      shell: bash

    - name: Publish Test Report
      if: ${{ always() }}
      env:
        GITHUB_USERNAME: ${{ inputs.PACKAGE_ACCESS_USERNAME }}
        GITHUB_TOKEN: ${{ inputs.PACKAGE_ACCESS_TOKEN }}
      uses: scacap/action-surefire-report@v1

Thanks for sharing, could you also share what triggers you have defined for this composite action?

name: feature-workflow
on:
  push:
    branches:
      - 'feature/**'
      - 'renovate/**'
      - 'hotfix/**'
env:
  APPLICATION_NAME: my-application-name
jobs:
  build:
    name: Build & Test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: "Checkout pliant github-actions"
        uses: actions/checkout@v3
        with:
          token: ${{ secrets.PAT_GITHUB }}
          repository: my-shared-repository
          path: ./.github/my-path

      - name: Build & Test
        id: build
        uses: ./.github/my-path/dist/build-and-test-job/
        with:
          JDK_VERSION: 17
          GITHUB_TOKEN: ${{ github.token }}
          APPLICATION_NAME: ${{ env.APPLICATION_NAME }}
          PACKAGE_ACCESS_USERNAME: ${{ secrets.PACKAGE_ACCESS_USERNAME }}
          PACKAGE_ACCESS_TOKEN: ${{ secrets.PACKAGE_ACCESS_TOKEN }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_PROJECT_KEY: infinnity-card_${{ env.APPLICATION_NAME }}

Thanks for sharing.

We recently made a change to our Github Actions configuration. When the scanner runs in the context of a push event, it will always configure a branch analysis instead of a PR analysis.

To get PR analysis working again you should add the

on: 
  pull_request

to your configuration instead of

on:
  push:
    branches:
      - 'feature/**'
      - 'renovate/**'
      - 'hotfix/**'

Would that work for you usecase?

You can also make use of the branches parameter of pull_request to stay aligned with your current configuration:

on:
  pull_request:
    branches:
      - 'feature/**'
      - 'renovate/**'
      - 'hotfix/**'
1 Like

I don’t think it will work for my use case, we are not strict with when exactly we’re creating a PR and we need to run tests and analysis on every push.

I’ll try to add this trigger to my project. But if it works I’d have to change this config for 15+ projects, which is not ideal.

Is there any reason why it was working but not working anymore?

I’ve just added

  pull_request:
    branches:
      - 'feature/**'
      - 'renovate/**'
      - 'hotfix/**'

to one of my existing PRs and the comment didn’t get posted anyway.
I closed the existing PR and “created a new one” which reopened existing one, does it have to be a new PR to work? What about new commits into existing PRs?

Hi,

Just to tell you, we had the same problem here on all repos of our open-source project. We tried many things, but in fact the problem got solved by adding on: [pull_request] in our CI. Thanks!

To give you more insights, our problem was

  • The Pull Requests were still being analyzed in SonarCloud, but not recognized as PR
  • The check was not being populated on the pull request in GitHub (EDIT: well in fact I just checked again right now it’s back, there’s even two checks: SonarCloud alerts check, by Github action, and SonarCloud Code Analysis quality gate check, by SonarCloud)
  • No summary comment was being posted in GitHub

you are right, id does publish sonar report now, but it also runs tests twice :frowning: one for push and one for pull_request.
No ideal

@TomVanBraband is there any other way to fix the issue?
Running tests twice per push (one for push and one for pull_request) is really not working for us.

Unfortunately, the only solution I see is to only use on: pull_request, and to always create a PR when creating a new branch.

GitHub actions does not allow you to easily set-up what you are looking for, see this thread

Can you give a bit more detail about which usecases you create a branch but don’t open a PR for that branch?

Our normal flow is that we create a branch, work on the branch and then publish a PR for code review. We do not require opening a PR immediately.
And one of the points of working on the branch is making sure that we do not create new vulnerabilities and maintain a certain level of test coverage.

My problem is not with github actions :slight_smile: my problem is that setup that was working previously is not working now without any changes on our side.

The reason why we changed the logic is because it was negatively impacting other users.

The logic we used to have was in case we run on a push event to use the GitHub API to see if the HEAD commit was included in an open PR. If that was the case, we would configure a PR analysis and post the comment to the found PR.

For some customers this was falsely flagging some analysis as PR analysis, when they were expecting a branch analysis. For example in the case where they would push on their main brach, but there was a PR open from the main branch into another branch. In that case they want to have a branch analysis, and not a PR analysis.

Therefore we decided to remove the custom logic and to fully rely on the GitHub actions context. I understand that this is affecting your workflow, but unless other users come with the same problem to the community, it’s not something we would change now.

In my case, using only on: push (NOT on: pull_request), the status check is posted when the project is bound to a github repo. In the same org (also bound to github), for another project which was created differently and not bound to github (although the project is really on github, it’s just an import difference, not sure why), the status check was not posted. Is this expected ?

Hi @jonenst,

This is expected. On SonarCloud side we need to know to which your SonarCloud project maps to on GitHub side to post the status check.

Hi, thanks for your time and your answer. However, the situation is still unclear. From what I see

  • project bound to github repo, using on:push => status checks posted on PR
  • project NOT bound to github repo, using on:push => status checks NOT posted on PR
  • project NOT bound to github repo, using on:pr => status checks posted on PR

are all these expected ?

You said “Therefore we decided to remove the custom logic and to fully rely on the GitHub actions context” but it still works using “on: push” for bound projects, can you please elaborate ?

According to Binding an existing project to Github, it is not possible to bind a project to github after its creation, what are we supposed to do ? I would like to avoid deleting and reimporting projects that have a multiyear history and were created before the github importer existed.

Thanks in advance,
Jon

Also, if the ticket says that binding is not available yet, how do I have my projects bound? If that fixes the problem with notifications on push, I would definitely want them to be bound

From what I see, it also adds some hyperlinks on commit shas, maybe other things ?
To have some one my projects bounds (the small ones), I deleted them and recreated them (lost history…)

@TomVanBraband
I’ve encountered the same problem and use cases as the OP. It was extremely frustrating to not only have this change made without any indication to consumers that this was changing, but to not provide any sort of override or optional solution to use previous behavior.

Aside from providing more opportunity of where and when to put PR comments, I think SonarCloud should also provide regular release notes, if there isn’t a place to view them already.

3 Likes