Pull request decoration has stopped working on some github projects in my organisation, despite the sonarcloud CI triggering successful analysis and the sonarcloud github app being installed in the organisation.
We made no code changes to trigger this Sonarcloud behaviour change, and pertinent github actions and sonarcloud credentials are identical between projects that work and don’t work with sonarcloud. Suggestions appreciated
DETAILS:
CI system: github actions
Languages: Predominantly Python, some JS
Error observed: Pull request decoration stopped appearing in Github PRs, despite Sonarcloud CI being triggered. We made no Sonarcloud code changes proximate to Sonarcloud errors.
I suspect that sonarcloud is not identifying our pull requests as pull requests, although I am not sure why that would have suddenly occurred when none of our CI code changed.
Can you suggest how to restore the pull request decoration? Thanks.
Your analysis is correct, in all the recent builds of your projects, the analysis is detected as a Short branch analysis and not as a Pull Request analysis.
To be detected as pull requests analysis, the action must be triggered on pull_request events, and not on push events (push events are fine for short and long branches, without pull requests opened on it).
You can see a configuration example here, on the README file:
This change happened on our side, not yours, that’s why the decoration stopped appearing without any change on your pipeline.
Do you think changing the trigger to pull request events would be possible?
I’m not really sure how the interaction works to make Sonarcloud trigger PR decoration. My understanding of the above file is that we return true on the push condition (as previously) so I’m not sure that the pull-request: condition being simultaneously met matters?
You should remove the branches you open pull requests on from the branches trigger, and keep only the branches without pull requests there.
For example, if you have 3 long branches, master, develop and release-6.5, you can configure them like this:
on:
# Trigger analysis when pushing in master or pull requests, and when creating
# a pull request.
push:
branches:
# any branch except PRs
- master
- develop
- release-*
pull_request:
types: [opened, synchronize, reopened]
The SonarScanner knows which trigger caused it to start. If it is triggered due to a push event, a branch analysis is configured. If it is due to a pull_request event, then a pull request analysis is configured, which is itself the trigger for the GitHub Summary decoration you miss.
Glad to hear that the decoration appears now.
About the coverage, if you look at the Summary page of that branch (on the left menu, click on “Pull requests”, then on your PR), is it showing coverage in the bottom left corner?
I found the problem: the restore-sonarcloud-decoration PR only edited yml files and had no changes to tested .py files. Adding python lines restored expected behaviour.
Sadly, the solution seems to have created a new issue.
While pull requests are now being identified, the Main Branch on sonarcloud has stopped being updated so the comparison in each PR analysis is increasingly stale and running against a now six-day old record of dev (despite those PRs being merged into dev)
Aha, and now I understand why the push was needed. Issue appears resolved. Thanks!
PS. typo in prior post. Need branch: in the push args
name: Maintain SonarCloud
# This Github Action keeps SonarCloud operational. That means facilitating PR decoration on all PRs, and keeping the
# SonarCloud `Main Branch` up-to-date for PRs to compare against
on:
# For Sonarcloud PR decoration to work, trigger must be pull_request.
# This is the most common way to trigger the sonarcloud flow.
pull_request:
types: [ opened, synchronize, reopened ]
# For Sonarcloud to keep track of "main branch" to compare PRs against, we need to trigger SonarCloud on pushes to
# that branch.
push:
branches:
- develop
{do pytest and sonarcloud}
