We currently have Sonarqube hosted within our organisation, behind a layer of auth. We’d like to get PR decorations working with our code repo hosted in ‘github.com’.
When we run a scan on our code, the scan works fine, but the PR decoration errors with:
'Failed to report status to Devops platform because the repository slug does not have the expected format 'organisation/repository': '<REPO_NAME>'. Check the project settings.'
I can confirm that the Devops Integration settings are in the ‘organisation/repository’ format and are all valid.
Github logs show what looks to be Github making a request to our hosted Sonarqube with a ‘GitHub-Hookshot’ POST request, and hitting our auth page. If Github needs to speak to our hosted Sonarqube then this will not work due to the way our auth is set up (we thought the PR decoration would require only one-way traffic from Sonarqube to Github).
Can anyone advise on this issue?
Possibly related to: SonarQube set up behind organization IdP - Causes issue with Github PR Decoration
Welcome to the community!
When you created your GitHub App, you provided a Webhook URL. Unfortunately, the docs aren’t clear about how that’s used, but it looks like two-way communication is needed for this to work.
Okay no problem, that’s what I thought. Thank you for the quick reply!
To be clear, this is how it works (one-way communication from SonarQube to GitHub). While a Webhook URL is defined, it’s never used for anything (you could set it to a junk URL). This might be a red herring in your PR decoration troubles.
Are there any other interesting web requests (SonarQube to GitHub) in the logs, ignoring the webhook reception?
In the Sonarqube logs there doesn’t seem to be anything out of the ordinary. Just logs confirming that the scan results were successfully pushed to SQ (this can be confirmed in the SQ UI), then the above error about the repo slug not being in the correct format. Again, the repo slug in our Devops Integration set up is in the correct “organisation/repository” format and has the green validation tick, however the error message only seems to show the “repository” part of the slug, as if the “organisation” part is not being picked up. It is a private GitHub repo but as I understand that shouldn’t make a difference.
In the GitHub logs we see this 302 check-suite error whenever a commit it made to a branch, which appears to be trying to reach out to our Sonarqube instance (which due to our setup it will not be able to reach). Not much else!
Let me suggest bumping up your log level an annoying amount (like to
TRACE in Administration > System > Log Level) and run a pull request analysis on this project. I’m happy to open a private message to share the logs (specifically the ce.log of your SonarQube instance’s /logs/ directory) if you’d like.
I’ve got some logs for you so if we could open a private channel that would be good.