Hello,
I setup a monorepo on my github repository. So now I got 4 sonar projects linked to an ‘not visible’ parent project. If I scan a branch, I got the sonar project updated, I can use the sonar badge, If I create a PR, I got sonar writing 4 comments with the scan result this is great.
But without mono repo, I did have a sonarcloud check on my PR. Now this check is missing. Is it something that has been removed because of monorepo ?
Hello @GregoireW,
Could you send me your organization and project key via private message (or post them here if it is a public project)? In general the check should also be available for monorepos, so we are going to investigate this issue.
Hello,
I can give you this open source project: github.com/decathlon/vitamin-web. The sonar organization is “decathlon” and linked projects are:
Thank you
Hello @GregoireW,
Thanks for your sharing those projects.
I think you might have a bug in your GitHub Action definition (build-pr.yml).
If we look at this PR we can see that the only commit in the PR has the following SHA1: 9ad9d68dc842d86c7b22ebc999768ea26bbfb246.
However when you look at the GitHub action that does the analysis we can see in the logs that the following SHA1 is checked-out: 978bffd54c915146ae74b4ec838b43378fc9635a (which is the latest commit on main).
So SonarCloud has been reporting checks, just not on the commit in the PR. SonarCloud also won’t be able to find any issues with this configuration since you are currently analyzing a merge of the main branch into the main branch.
Everything should work as expected once the configuration of your actions/checkout@v2 step is fixed.
Hope that helps!
Hello,
I will check that (and I remember I had to manage thoses parameters when doing merge and check on PR).
-Dsonar.pullrequest.key=xxx
-Dsonar.scm.revision=xxxx
Thank you.
Great, definitely let us know if it still doesn’t work.
These parameters are actually not necessary when you are using the SonarCloud GitHub action. We autodetect them from the GitHub environment. Feel free to remove them
Ok, not fixed yet, but this has to do with pull_request_target event vs pull_request event.
We can fork this repository, so we use pull_request_target event which do not manage the git ref the same way standard pull_request do. On some part, we force the checkout of the source branches but not on the sonar check step. I need to check if I can get the merged branch like pull_request do.
Thanks for sharing @GregoireW! I moved your posts into a new topic so people can easily find them in the future.
Hello,
Hum… Sorry, I got a ping from somebody. We should never use pull_request_target with checkout there is a big security issue ( https://securitylab.github.com/research/github-actions-preventing-pwn-requests )
As I cannot edit previous post, I deleted it.
I guess my problem will be resolved when this issue https://jira.sonarsource.com/browse/MMF-1371 will be.
added a comment, but the issue is definitely not easy to solve.
@GregoireW Thanks for the link to the security issue for pull_request_target.
Maybe someone can explain to me why it is a bad idea to allow the special user Anyone to run the analysis.
Let say you have an opensource project, I create a PR with lot of code to fix an issue. Sonar check is green so you think my code is good. What you don’t know is sonar did detect some big issue and the check was red but I did send with the “Anyone” account from my computer a report that make sonar think the PR is OK, so that sonar will sent to GH a green check.
Perhaps you will notice some big red alert when you merge to main branch, but perhaps not ( focus is usually on PR).