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

I’ve just added

      - '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?


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,

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…)

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.


Wow, I spent few hours wondering why sonarcloudbot messages are gone…

Same, and aside from the unexpectedness of the change, the poor communication/notification of it added some salt to the wound.

I think I follow why the change was made at a high-level, but that doesn’t really obviate the need to work with the folks whose cases would be broken by it at least imo. Or maybe I just missed where messaging about this had been done previously perhaps?

I would still like to have a more precise description of what is expected to happen, because it’s not what has been described in this thread:

“Therefore we decided to remove the custom logic and to fully rely on the GitHub actions context.”

conflicts with my observations (1st one):

project bound to github repo, using on:push => status checks posted on PR (is this expected ???)
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

Can you comment on this ? Thanks

I’m also struggling how should it be configured.
I think in past days this configuration was pushing bot message, but right now not. Another update?

      - '**'
    types: [synchronize]

It’s upsetting that this change was made with no notification, as we previously just ran sonar on branches, and not on PRs, and relied on the comment from that branch analysis on the PR. Now we have to run sonar on both branch and PR, which consumes more actions minutes.

Is there no way this could become a setting of some kind for us to customize?

I understand that we disabled behaviour that you were relying on, and we apologise for the lack of communication on this change.

We’ll start internal discussions on how we can support both usecases, since the logic we disabled was also negatively impacting some of our users.

We’ll consider this option, thanks for the suggestion.

I’ll update this thread once we have more information

1 Like

Can you share wether you are referring to the commit check or PR summary comment when you say ‘status checks’?

When you have a bound project, you should always receive a GitHub check on your commit, wether you use on: push or on: pull_request. With the recent change you should now no longer receive a PR summary comment when using on: push, but you should receive a PR summary comment when using on: pull_request