Avoid getting summary comment on main repo PR from fork with matching PR number

[radnov]

• ALM used (GitHub)
• CI system used (GitHub Actions)
• Scanner command used when applicable (mvn sonar:sonar)
• Languages of the repository (Java)
• SonarCloud project (https://sonarcloud.io/organizations/dhis2/projects)

Error observed:
GHA workflow runs triggered from pull requests in repository forks send “Summary comment” to the main repo, if the PR number is the same.

Potential workarounds:

• Disable “Summary comment”
• Disable “Execute Analysis” permission for “Anonymous” members

Example:
This “Dependabot” Pull Request in a forked repository sent a “Summary comment” to a Pull Request with the same number in the main repository.
And here is the failed Quality Gate summary in sonarcloud.io - as you can see, the details are mixed - the “head” and “base” branches are the ones from the main repository PR, while the commit that triggered the check is from the fork repository PR.

Is there a way to avoid this behaviour, besides the potential workarounds listed above?
I assume this isn’t considered a bug, because I found a mention of it in this post, which was acknowledged by a SonarSourcer, but only regarded as “a bit difficult”.

Another thing that seems a bit strange is that the next PR #33 in that fork (from the example above) failed the SonarCloud check with

You're not authorized to run analysis. No sonar.login or SONAR_TOKEN env variable was set.

but nothing had changed for that workflow setup meanwhile.

[Colin]

Hey there.

Thanks for the report. I suppose we haven’t run into this issue before because we generally this isn’t done:

• Disable “Execute Analysis” permission for “Anonymous” members

Am I right to assume you doing this specifically to allow analyses to happen from forked repos without sharing a secret?

I do think this is odd behavior we should look into – and, a user recently shared a workaround for analyzing forked repos with GitHub Actions. Maybe you could give it a try and see if it works just as well for you?

How to use SonarCloud with a forked repository on GitHub?

Hello all– After much struggle, we now have a Github repo that can run SonarCloud analysis on pull requests from forks. The trick is the “workflow_run” feature from Github Actions: In short, you need 2 separate Github Actions: Build step - Build your project, run tests, upload code coverage. This step does not have access to any Github secrets such as SONAR_TOKEN. Sonar step - Download code coverage from previous step, and run the SonarCloud analysis. This step does have access to SONAR_…

[radnov]

Hey, thank you for the response.

@Colin

• Disable “Execute Analysis” permission for “Anonymous” members

Am I right to assume you doing this specifically to allow analyses to happen from forked repos without sharing a secret?

No, we disabled “Execute Analysis” for “Anonymous” members in order to avoid the issue of getting Summary Comments on PRs in the main repo (usually old ones) from PRs in forks (within the fork repo itself, as in the Dependabot example above).

However, with anonymous execution disabled, we can’t run scans on PRs from forks to the main repo, because the secret isn’t shared between the different orgs.

I saw the workaround Cody Ebberson shared in his post, but haven’t tried it yet. Still, that only solves half of the problem for us.

[radnov]

@radnov

Another thing that seems a bit strange is that the next PR #33 in that fork (from the example above) failed the SonarCloud check with

You're not authorized to run analysis. No sonar.login or SONAR_TOKEN env variable was set.

but nothing had changed for that workflow setup meanwhile.

Actually, I was wrong here - we had disabled “Execute Analysis” for anonymous members (“Anyone”) just before that error occurred, so it’s expected.