How to use SonarCloud with a forked repository on GitHub?

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: (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: (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?


sonarlint CLI should / can not be used for scanning locally anymore:!msg/sonarqube/WlALjVzp-OE/Ev3QpnaOBAAJ

Another discussion hitting the same pain point for open source projects with forks:!topic/sonarqube/4bzwxkqJGAc

The pull request feature is very nice, but for our concern not applicable, because most of the people creating pull requests are not permitted to create a branch in our repos.


Bringing the pull request decoration on external PR is on our plan: MMF-1371. Unfortunately I can’t give you an ETA.

1 Like

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?

1 Like

Are there any news? The Issue is not so active :slight_smile:

Bump, any news on that?
Our setup in Jenkins is that we have people all over the world using forks to contribute to repositories, we’d love to use SonarCloud integration to get feedback on the PRs from external forks.

What will happen if I hard code the sonar token into the workflow yml file?

We cannot recommend adding secrets to version control.

Not yet!

Not yet! I recommend to check again after 4-6 months.

1 Like

Not yet! I recommend to check again after 4-6 months.

how is it going :slight_smile:

We still don’t have an ETA, and it won’t happen before the end of the year.

We do recognize this is a highly wanted feature, and I hope we’ll be able to squeeze it in our roadmap for next year.

Feel free to ping us again after 3+ months.

bump. Any updates on this?

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.

Feel free to ping us again after 4-6 months.

What do you think - what difference will be:

  • anonymous (without token) analyses supported by sonar
  • token in code for technical account which has only analyses permission

Any news on this. I also work on an OSS project where we all use forks. We don’t feel comfortable adding secrets into the repo, which means we can’t use sonarcloud for PR decoration.

Whilst the sonar results are great, they are rarely looked at. To be effective we MUST have scans/changes being shown within the development cycle, or at PR/review time.

We are now using codeQL and Lift instead as Sonar cant do this (even though we like the reports and scans the best overall, if they’re ignored, there’s no point)

I hope we can see this issue being addressed soon. This is such a normal way of working in open source

Hi Nigel,

Unfortunately we do not have any update on this topic at this time.
We do agree that this is an important issue for us to tackle.
I will nudge product management.

Any news on this?

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.

Unfortunately, I have no update from product management at this time.

Hello everyone!

You can now subscribe to future updates and provide feedback on this feature on our roadmap page: SonarCloud analyzes external Pull Request - SonarCloud | Product Roadmap .

We still do not have an ETA, but this is a frequently requested feature for SonarCloud and we want to remove the friction as soon as possible.

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:

  1. Build step - Build your project, run tests, upload code coverage. This step does not have access to any Github secrets such as SONAR_TOKEN.
  2. 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.


Thank you for sharing this. We will surely try this out. If this works then we can stay with Sonar for longer.

1 Like