Sonarcloud intermittently fails to report status to GitHub

SonarCloud
,
1

When performing analysis of projects on Sonarcloud, the results of the analysis sometimes do not get reported to GitHub as status checks.

This problem is intermittent, affecting multiple projects in our organization (using Python, node.js, Swift, Java and more). We can’t reproduce it reliably, and it’s usually resolved by re-running the analysis via CI.

The SHA in the PR head matches that of the analysis.

We use CircleCI to run the scanner, an example context is inline below.

Does anyone have any ideas as to how to address this issue?

SonarQube plugins:
- SonarCSS 1.1.1.1010 (cssfamily)
- SonarPLSQL 3.4.1.2576 (plsql)
- SonarScala 1.7.0.883 (sonarscala)
- SonarC# 8.0.0.9566 (csharp)
- Vulnerability Analysis 8.0.0.5505 (security)
- SonarJava 5.14.0.18788 (java)
- SonarHTML 3.2.0.2082 (web)
- SonarFlex 2.5.1.1831 (flex)
- SonarXML 2.0.1.2020 (xml)
- SonarTS 2.0.0.4283 (typescript)
- SonarVB 8.0.0.9566 (vbnet)
- SonarSwift 4.2.1.62 (swift)
- SonarCFamily 6.4.0.11646 (cpp)
- SonarPython 2.0.0.5043 (python)
- JaCoCo 1.0.2.475 (jacoco)
- Mercurial 1.1.2 (scmmercurial)
- SonarGo 1.7.0.883 (go)
- SonarKotlin 1.7.0.883 (kotlin)
- SonarTSQL 1.4.0.3334 (tsql)
- SonarApex 1.7.0.883 (sonarapex)
- SonarJS 6.0.1.10206 (javascript)
- SonarRuby 1.7.0.883 (ruby)
- Vulnerability Rules for C# 8.0.0.5505 (securitycsharpfrontend)
- Vulnerability Rules for Java 8.0.0.5505 (securityjavafrontend)
- License for SonarLint 8.0.0.2514 (license)
- SonarCOBOL 4.4.0.3403 (cobol)
- Git 1.10.0.1891 (scmgit)
- SonarPHP 3.2.0.4868 (php)
- SonarABAP 3.8.0.2034 (abap)
- Vulnerability Rules for PHP 8.0.0.5505 (securityphpfrontend)
Global server settings:
- email.from=noreply@sonarcloud.io
- email.fromName=SonarCloud
- email.prefix=[SonarCloud]
- sonar.auth.bitbucket.enabled=true
- sonar.auth.microsoft.enabled=true
- sonar.core.id=****
- sonar.core.serverBaseURL=https://sonarcloud.io
- sonar.core.startTime=2019-11-08T09:14:19+0100
- sonar.cpd.cross_project=false
- sonar.dbcleaner.weeksBeforeDeletingAllSnapshots=480
- sonar.dbcleaner.weeksBeforeKeepingOnlyOneSnapshotByMonth=4
- sonar.dbcleaner.weeksBeforeKeepingOnlyOneSnapshotByWeek=1
- sonar.java.collectAnalysisErrors=true
- sonar.leak.period=30
- sonar.lf.enableGravatar=true
- sonar.lf.logoWidthPx=105
- sonar.organizations.anyoneCanCreate=true
- sonar.organizations.createPersonalOrg=true
- sonar.plsql.file.suffixes=sql,tab,pkb
- sonar.tsql.file.suffixes=.tsql
Project server settings:
- sonar.branch.longLivedBranches.regex=****
Project scanner properties:
- sonar.analysis.scmRevision=****
- sonar.branch.name=****
- sonar.coverage.exclusions=****
- sonar.coverageReportPaths=****
- sonar.cpd.exclusions=****
- sonar.host.url=https://sonarcloud.io
- sonar.inclusions=****
- sonar.login=******
- sonar.organization=****
- sonar.projectBaseDir=****
- sonar.projectKey=****
- sonar.projectVersion=master
- sonar.scanner.app=ScannerCli
- sonar.scanner.appVersion=4.2.0.1873
- sonar.sourceEncoding=UTF-8
- sonar.sources=****
- sonar.verbose=true
- sonar.working.directory=****
3

Hi @jonadaly, welcome to the community forum!

Could you share your CicrleCI config.yml and the logs of a CircleCI build that failed to report the status as a GitHub check?

My apologies for the delay,
Tom

4

I don’t think the CircleCI -> SonarCloud communication is the problem, as I can see the analysis running in SonarCloud consistently.

What isn’t consistent is the SonarCloud -> GitHub status check reporting.

Re-running the workflow is CircleCI generally solves the problem, so it’s unlikely to be a problem with the CircleCI config or the scanning itself.

I’m reluctant to attach the logs in a public forum as they contain sensitive information, but I’ve attached a simplified config file:

config.txt (1.9 KB)

5

When you push a commit and open a pull request for that commit a few moments later, the CircleCI build will already have been triggered (but without the pullrequest metadata, because the pullrequest was not yet opened). In that case the scanner is configured to trigger a branch analysis, and a branch analysis will never update a GitHub check. Re-running that build when a pull request is already opened will trigger pull request analysis and that will update the GitHub check.

Does that match the behaviour you are experiencing? There is a CircleCI idea open that would fix this.

PS: We recently updated our scanner to detect CircleCI environment variables, so you can simplify your CircleCI config.yml by removing this part of your config:

if [[ ! -z ${CIRCLE_PULL_REQUEST} ]]; then
   ADDITIONAL_ARGS="-Dsonar.pullrequest.branch=${CIRCLE_BRANCH} \
                -Dsonar.pullrequest.key=${CIRCLE_PULL_REQUEST##*/} \
                -Dsonar.pullrequest.provider=github \
                -Dsonar.pullrequest.github.repository=${GIT_SLUG} \
                -Dsonar.pullrequest.github.endpoint=https://api.github.com"
else
   ADDITIONAL_ARGS="-Dsonar.branch.name=${CIRCLE_BRANCH}"
fi
1 Like
6

Thanks for the heads up, will give it a go removing that config!

No, that doesn’t match the behaviour we’re seeing. We always trigger a fresh CircleCI build when a PR is opened, so the PR analysis always runs and should report its status back to GitHub. However, sometimes it just… doesn’t.

7

Ok, I was basing myself off of the fact that you only have the property sonar.branch.name set in the scanner context you shared in the initial post, which lead me to believe that a branch analysis was triggered instead of pullrequest analysis.

Could you share the analysis ID and context of a background task that failed to update a GitHub check? You can find this when navigating to your project on SonarCloud and then clicking on Administration > Background tasks.

1 Like
8

Apologies Tom, I think you may be right - it appears we only sometimes trigger a fresh build when a PR is opened. I suspect this may be the answer, but I need to investigate a bit more.

1 Like
9

Yep - you’re right. When the PR is opened after the scan has run, then (obviously) it’s a branch analysis instead of a PR analysis and the status will never get reported.

I wish CircleCI would have the option to trigger a workflow when a PR is opened…

Thanks for your help!
Jon

1 Like