We are using GitHub together with SonarCloud to check also pull requests.
With the recent removal of the preview mode it is not possible to run checks on pull requests from forks.
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:126.96.36.1994:sonar (default-cli) on project jpasecurity: The preview mode, along with the ‘sonar.analysis.mode’ parameter, is no more supported. You should stop using this parameter. -> [Help 1]
Removing the mode parameter results into:
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:188.8.131.524:sonar (default-cli) on project jpasecurity: You’re not authorized to run analysis. Please contact the project administrator. -> [Help 1]
So how can I enforce pull requests from forks to get checked with sonar?
I know about that feature plans, but it doesn’t improve the situation at the moment.
With removing the preview analysis option, it is not possible to have at least one check before getting stuff merged into your own repository.
Before it was possible to run the scanner in preview / issues mode to get an analysis of the changed sources.
What is the official statement of SonarSource to keep running the environment like that?
Bump, any news on that?
Our setup in Jenkins is that we have people all over the world using forks to contribute to https://github.com/jenkinsci/ repositories, we’d love to use SonarCloud integration to get feedback on the PRs from external forks.
As far as I know this topic did not become an explicit target on our roadmap for the year. That doesn’t mean it won’t happen, it just didn’t make it into the top. This is very important to us, and we’ll try to squeeze it in our monthly plannings.
Having failed sonarcloud analysis on each PR is pretty bad since we can’t share secrets to forks. I love Sonarcloud and would love to use it for our OSS but right now, I’m checking for alternative that truly support OSS.
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_TOKEN.
The reason this works is because the 2nd step uses Github Actions from main/master, not from the pull request. That way you can be confident that the PR didn’t modify the build scripts, and leak all of your secrets.
Our repo here:
Build action here:
Sonar action here:
Here is some excellent background reading from the Github security team about why all of this is so complicated:
If folks are interested, I can write up a more detailed explanation. Hope this helps someone. Today is the first day we ran Sonar analysis on a PR from a fork, and it felt great.