SonarCloud analysis fails because only GITHUB_TOKEN is available in pull requests from forks

[lg2de (Lukas Grützmacher)]

I seems to be a common problem to get together SonarCloud and github actions: Full Sonar analysis is only available when executed in the build pipeline. Otherwise, e.g. the test coverage is not available. Running this analysis in github actions, the SONAR TOKEN is required to upload the analysis result. But, secure values like the SONAR TOKEN is not available for pull requests from github forks for security reason.

All my research so far results in the answer: There is no full solution available for fork pull requests. But, this is the most important analysis when external developers are adding code.

I can’t really believe that SonarSource is willing to just accept the situation. Can’t SonarSource and GitHub work together to find a secure solution? Or have I just overlooked this secure solution?

[Colin]

Hey @lg2de

You might be interested in this thread:

Configuring a secured GitHub workflow to launch a Sonar analysis for PR from forks

So, as promised, here is how we managed to get a Sonar analysis on a PR based on a fork. We now have 3 CI workflows: “CI”: the usual one that works only on PR from inside our repository and therefore can access the secrets “CI on forks - build and tests”: the workflow that run only on PR from forks. It does all the parts that do not require access to the secrets (building and testing) “CI on forks - Sonar analysis”: this workflow is triggered only when the “CI on forks - build and tests” succ…

Additionally, I’d like to mention that Automatic Analysis supports the analysis of PR from forks. So yes – you’re missing out on coverage data, but it is an option.

[rolnico (Nicolas Rol)]

@Colin Do you know how I could do to edit the solution I provided in the thread you linked? There are some elements that I had to fix for security reasons.

Also, regarding the security advisory on your action (that I use here) and the advice you provide in this message, I should also edit my solution to remove the quotes around the different parameters, right? Since, for example, I provide a list of source directories via -Dsonar.sources="${{ env.SOURCES }}"

[Colin]

Hey @rolnico

Unfortunately editing old posts is a bit tricky in Discourse. There’s a time limit for non-staff users, and I can’t change that for one post / one user.

That said, I’ve unlocked the topic if you’d like to add an addendum in a new post!

@rolnico

Also, regarding the security advisory on your action (that I use here) and the advice you provide in this message, I should also edit my solution to remove the quotes around the different parameters, right? Since, for example, I provide a list of source directories via -Dsonar.sources="${{ env.SOURCES }}"

Let me check on that. I don’t think you have to remove the quotes, but I haven’t tested it myself.

[shamoon]

One step forward two steps back for us. Just hitting this and agree, it’s kind of a showstopper for CI analysis. The whole reason we tried to move to it (instead of automatic) was for coverage… which we still cant get?

And the linked solution, though an option, seems incredibly hack-y and complex (aka error-prone).

[shamoon]

Also, people implementing these workarounds are giving up in the end: Move Sonar and Coveralls back to Build action by codyebberson · Pull Request #7437 · medplum/medplum · GitHub suggesting they are not a viable.

At the very least I think this limitation should be very clear, we would not have even pursued setting up analysis in CI (turned out to be a good amount of work) if we’d known it wouldn’t work in forks.