Must-share information (formatted with Markdown):
- SonarQube Developer Edition 7.7.0; Gradle plugin version 2.7
We have multiple different GHE deployments in the company (don’t ask why ). Most of our repositories are on one of them, so general pull request configuration is done via the SonarQube UI (and that works).
Is it possible to configure a different GitHub App ID, private key, and so on per repository/analysis?
I tried to configure it via
-D system properties on the Gradle command line via Jenkinsfile, but no luck. SonarQube then displays this warning:
Nothing in any of the logs.
GitHub Apps were created by me in exactly the same manner on both deployments.
Apparently it is not possible to supply the GitHub App private key, ID and endpoint via command line options? Any way to make this happen at all?
Sorry, but that situation never even crossed our minds. The GHE info must be provided server-side because IIRC decoration happens asynchronously; by the time we’re decorating, we’re no longer in the context that has analysis-passed values.
thanks for your reply
I just fiddled with the SQL database, and inserted the relevant keys there on project level (which is not possible via the UI). This is probably a hack, but at least the values showed up in the “Project server settings” section of the corresponding Scanner Context (via Background Tasks tab).
I then increased log-levels on the compute engine, and found this:
2019.04.11 14:10:24 TRACE ce[AWoMTl8UXKBUdgd6Tv8r][sql] time=0ms | sql=select p.prop_key as "key", p.is_empty as empty, p.text_value as textValue, p.clob_value as clobValue, p.resource_id as resourceId, p.user_id as userId from properties p where p.prop_key=? and p.resource_id is null and p.user_id is null | params=sonar.alm.github.app.privateKey.secured
Since it says
and p.resource_id is null, the “Project server setting” is effectively excluded from the result, and it uses the global server setting only.
I couldn’t find any log entries directly related to the PR decoration, though. I would have expected some exception to be logged?
Anyway - is there any chance to configure multiple GHE servers with a future version?
I’m obligated to slap your hand for directly updating the DB. It’s supposed to be a black box, and while it’s unlikely, it’s possible the rogue values you added could cause problems in the future. You really should undo your changes.
Regarding enabling this in the future, so far yours is an isolated case. I won’t say the door is closed on this, but we’d need more evidence of a broad benefit before we moved forward.
Thanks for understanding
Sure, already did
Thanks for the quick reply!
SonarQube v8.1 was released yesterday and includes the ability to define multiple instances of the same ALM for PR Decoration, stating in the Enterprise Edition.