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