Waiting for status of Github check of Sonarcloud when using Github Actions

SonarQube Cloud
, ,
1

Description

We’re trying to split our Github actions and move Sonar code analysis to a separate workflow that is triggered after our Java CI workflow was completed successfully. Most of it looks good and promising but the check result is not reported anymore. It worked before when we executed Sonar within the Java CI pipeline. I can observe:

  • Sonarcloud adds the comment “Kudos, SonarCloud Quality Gate passed!”
  • I can find the PR on Sonarcloud

The code change was about moving the execution of the Gradle task to a new workflow that is triggered “on.workflow_run”.

Since our project is open source you can also have a look at the code changes:

Versions used: Sonarcloud, Gradle plugin 3.3

Any help is appreciated.

Thanks,

Christopher

2

Hey @christopher-cudennec,

Welcome to the community!

There is quite a big difference in a way Github check and Github summary comment are added. Github summary comment is added in the context of the PR, whereas Github check is for a specific commit (does not matter if it is a PR or any other branch).

Are you sure that you are running the analysis on the commit that corresponds to the PR commit? I can see in the SonarCloud that the SHA of the commit is 877ea1ba where Github shows me 3b265149

Best,
Marcin

4

Hey Marcin and thanks for looking into our issue! :slight_smile:

I’ve double checked the commit SHA but I’m pretty sure it matches our last commit:

But still we don’t get the check result from Sonarcloud.

I did one change after your comment: When checking out the repo at the start of the workflow run, you can either checkout the branch or the exact commit SHA. I changed it to the latter: chore: Sonar workflow checks out exact commit that triggered the work… · SDA-SE/sda-dropwizard-commons@3405e48 · GitHub

Anything else that looks suspicious to you?

Cheers,

Christopher

5

Hey @christopher-cudennec,

I checked out the logs for the PR 1213 and the computed revision that we tried to decorate is: 3405e (run from the morning around 8:00). This kind of answers why you do not see the check on revision c8395.

The 3405e revision actually corresponds to the latest commit in the master branch. When looking at the previous analysis of this pull request, we also computed 1778b7 revisions which are also part of your master branch. I suspect that there may be some issues in the way the code is checked out and for some reason the analysis run on the master branch. Would you be able to verify it? For example print out the sha of the commit in the action?

Best,
Marcin

6

Hi @Marcin_Majewski !

I added the current commit SHA to the output of the workflow. IMHO it shows the correct commit SHA. Please have a look here:

Somehow the error must be connected to executing “sonarqube” in the workflow run. When we had it as part of the “Java CI” workflow it worked smoothly. Can you spot another error on our side?

Cheers,

Christopher

7

Hi @christopher-cudennec,

Can you run the scan with the debug flag? It would help to see some logs of scanner. For this purpose you have to set:

-Dsonar.verbose=true

Best,
Marcin

8

Sure, builds are running :slight_smile:

Do you think it makes sense to override sonar.scm.revision?
Documentation says:

By default value is provided by the CI environment or guessed by the checked-out sources.

If there is a problem with guessing we could override it with the commit SHA.

Cheers,

Christopher

9

Yes, overriding the sonar.scm.revision should fix the problem, as this value will be taken into consideration when creating a GitHub check. Let me know if this fixes problem for you!

You can also check out this thread: SonarCloud Code Analysis Expected- onoging issues - #57 by HofmeisterAn where there is a user with a similar problem (I think) as you.

Best,
Marcin

10

Overriding sonar.scm.revision fixed it. Although I’d say it’s really strange (even a bug?) that the plugin could not guess the right revision.

@Marcin_Majewski : Thanks a lot for your support!

11

Indeed, there has to be specific configuration here, that does not allow scanner to figure out the correct revision. I will look into the logs and see what I can find

12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.