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