We’re running a trial of SonarCloud and everything was going great until our testing branch was merged into master. Now I can’t get it to decorate / report back on the pull requests on GitHub.
We have recently changed the way we decorate pull requests on GitHub. In the past we used Reviews, today we’re using Checks. The user interface is a bit different, so first I would like to make sure that you’re not simply overlooking it. Please verify the following, even if they may seem trivial, as sanity checks:
Does the pull request have any open issues?
On the page of the pull request on SonarCloud, is there a warning in the top-right corner? It may have text like “Last analysis had 1 warnings” with yellow background. The warning may contain a clue.
On the PR’s page on GitHub, there should be a new tab named Checks (after Conversation and Commits, and before Files changed). On that tab, do you see a check labeled SonarCloud?
On the Conversation tab, at the bottom of the page there should be a line with the SonarCloud status of the pull request. Is there such line, and what does the text say?
If the project is open-source, it will help a lot to share a link to it, and to a pull request where you think decoration should happen but you don’t see it.
There are no open issues. Does it need to find issues to decorate?
There is a warning in SonarCloud “SCM provider autodetection failed. Please use “sonar.scm.provider” to define SCM of your project, or disable the SCM Sensor in the project settings.”. This makes sense as the scanner is run from a docker container. We copy over the source, run tests and produce a coverage report. We then run the scanner using this report. Could this be an issue?
There is a check labeled SonarCloud, it says " SonarCloud Queued 3 hours ago". Clicking re-run has no effect
The SonarCloud check isn’t displayed on the Conversation tab, just our CI check
The project isn’t open source unfortunately, we’re trialing SonarCloud on our most updated repo which is internal.
Hey. We use sonar-scanner from within a docker container during a jenkins build. It was working which is why I’m very confused as to what might have changed. The scanner context from a recent PR run is below.
Yes, this prevents the decoration. The decoration requires the sha1 of the HEAD of the pull request. The Git plugin picks this up during the scan, and the scanner writes it to the report sent to the server. If the SCM provider was not detected as Git, this won’t happen, and so no decoration will happen. This also explains what you seen on GitHub about the pending check.
I have not yet seen a use case of copying sources to run a scan. Would it be possible to copy the .git folder too, or clone from the sources instead of copying, or some other way so that you have sources + SCM data too?
The reason why it was working before is related to the change of GitHub API to decorate. The previous method (using Reviews API) could work with PR numbers without precise commit sha1, the new method (Checks API) requires commit sha1.
One possible remedy I can think of is to add a new scanner parameter to override explicitly the commit sha1 to use. I just don’t know if there is significant demand for this use case.
ah ok. Thanks! I’lll try copying over the git files too and if that doesn’t work checkout from within the container.
If you’re interested in our use case (which I’m not sure is that common but anyway…). We use docker multi stage builds and run all tests from within a builder container we create as part of the multi stage builds. Reasoning being we use macs to develop on but linux to host our deployments. Running everything inside the containers keeps the environments consistent.
The status line “SonarCloud Code Analysis” belongs to the new way of decoration. It looks like it’s working.
The status line “SonarCloud” with the message “Expected — …” is a mystery to me. The “SonarCloud” context was indeed used in our previous way of decoration, but I don’t see how such state is possible. And a non-green status should have become green when the new decoration came into effect. If you push a new commit and re-analyze, that should make that line go away. Let me know if it doesn’t, and if you have a way to reproduce it.
Yes, the new way is working. Uninstalling SonarCloud and reinstalling it did not remove the “Expected” requirement. We had to go into our GitHub repo settings > branches > edit to remove the required check. We expected the uninstall to automatically do that. No biggie, we now have it working with the new app.
I’m now running the scan from within the checked out directory and I’m still not getting any PR decoration or checks on the conversation tab in github. I’m not sure if it could be a problem, but how our jenkins build works is it merges master into the branch and creates a new branch named PR- eg PR-123. I think this is standard jenkins behaviour though, and we don’t build the actual branch during pull request as we don’t care about it. But I guess github wont have the same sha1? I’ve tried changing sonar.pullrequest.branch to both the jenkins branch name and the branch name of the PR but no dice. I’m not sure if this is the cause.
We’re over halfway through our trial now and I’ve been spending time trying to fix this rather than actually getting to try the product which isn’t great.
It will not have the same sha1, and that is a problem. SonarCloud will decorate the sha1 of the working tree that is being analyzed. If that’s not the same as the sha1 of the HEAD of the PR on GitHub, then you won’t see it on the PR on GitHub, because GitHub only shows Checks and Statuses for the sha1 that match the HEAD…
Mystery solved, and the next post in this very thread hinted at that too: the status is “Expected” when the admin of the repo configured to require the check. (And SonarCloud cannot clear that setting, only the admin of the repo can.)
If you only need the HEAD sha1 I’d definitely argue having an option to add this as a parameter would have been great for us as well as now we have to jump through hoops to include the .git folder which is never included in our docker builds normally.