How to use SonarCloud with a forked repository on GitHub?

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 https://jira.sonarsource.com/browse/MMF-1371 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 https://github.com/jenkinsci/ 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.

3 Likes

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

1 Like

Okay, I’ve finally managed it. @codyebberson’s version didn’t work for me, cause workflow_run event data doesn’t have pull request info and pull_requests array contains pull requests to fork and not to upstream.

So, this is my version with comments.

First of all you need to save PR number from pull_request event. You can achieve this by echoing data from event to file and upload it as artifact:

And then…

In a separate workflow with workflow_run trigger you need to:

  • download artifact from workflow that triggered the current workflow
  • read it to workflow data
  • get PR data via github rest api
  • checkout repo (from fork)
  • fetch base branch from upstream - this is important step! If you won’t do it, your “new lines of code” metric will be broken if fork has not synchronized base branch (and who do it nowdays?)
  • and at last - run analysis on push or on pull request grabbing all collected data

“Java CI” workflow logs: recreate: Исправил FP · 1c-syntax/bsl-language-server@3a6192c · GitHub
“QA” workflow logs: QA · 1c-syntax/bsl-language-server@2211575 · GitHub

There is some room for improvement (fetch only selected branch from upstream, protect from pr from branch with the same name as base branch), but I hope this will help someone.

1 Like

Thanks so much for sharing this @nixel2007 as I was stuck implementing the suggestions above!

I am almost there, but I am a bit stuck with one part which maybe you can help me with.

I’ve created the sonar.yml in the default branch:

I made some tweaks as we needed to specify some args and use a properties file for that, but otherwise it’s the same as yours without the platform-specific stuff, I think (as best I can tell, I’m no expert with GitHub Actions and not a developer!)

Then I have a PR I’m using to test which introduces the properties file and adds the parts to the tests.yml file we already have:

This is working great, it’s saving the PR number to the text file, and sonar.yml is picking this up.

The bit where I am struggling is that when it runs the scan on PR for example, it’s throwing up this error:

Warning: Unexpected input(s) ‘number’, ‘full_name’, valid inputs are [‘route’, ‘mediaType’]

It seems like it’s actually getting the information but maybe not in the right order? I’m not sure:

Run octokit/request-action@v2.x
with:
route: GET /repos/{full_name}/pulls/{number}
number: 13

full_name: RCheesley/mautic
mediaType: {}
env:
GITHUB_TOKEN: ***

GET /repos/{full_name}/pulls/{number}
> number: 13
> full_name: RCheesley/mautic
> mediaType: [object Object]
(node:1740) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
< 200 346ms

On the PR the GitHub Actions I have reporting are showing like this:

I think it’s running against the whole repo rather than the PR, I’m not entirely sure to be honest.

Any nudges you might be able to offer would be much appreciated!

(I haven’t yet added in the code coverage part as I didn’t want to complicate matters!)

May not be entirely the ‘right’ way but I managed to get it mostly working as follows:

I had to make the coverage report from Codecov readable by Sonar and then upload it as an archive so that we can access it in the next step.

Did the same with the PR number as suggested by @nixel2007 above:

Then grab the PR number per the example above:

Download the code coverage artifact and extract it:

Make sure that the file can be accessed within the container (hat tip to @sylfabre in this post)

Scan on PR:

We use a project properties file so I included that in the args, the file is here:

Obvs as this is running on my own fork I had to make quite some tweaks to some of the files as we restrict our actions to running only on our main repo and our private security repo, and had to hard-code a couple of path changes to work on my own fork while I figured it out.

Thanks to everyone for the help so far!