We wonder if it will be possible to specify different GitHub Application settings for Pull Request plugin for each project.
At the moment (7.7) there is only global settings for setting:
Which we found is very unhandy for our GitHub Enterprise use case. Basically we have plenty of teams working in separated projects with miscellaneous CI configuration.
Another problem with one GitHub application is one Webhook API - in this scenario we can’t simply hook our Jenkins Job as webhook and rebuild report.
Of course I’ve tried to set those properties in my
sonar.properties file, but those are simply ignored, didn’t help to execute sonar-scanner (126.96.36.1998) with
Expose properties that are used by Pull Request plugin to Project Level, so that they can be overridden for each project separately.
If I understand correctly, you have one GitHub Enterprise and one GitHub App per project in your GitHub Enterprise (meaning one GitHub Enterprise instance and several GitHub App that would like to configure per project), is that correct ?
If I may, how many different GitHub App do you currently have?
Hi, that’s correct. We have one GHE, with approximately c.a. 30 projects. Some of them use Jenkins to build, some other CI solutions - inhouse included.
Problem with the current - one global GH Application is that we have only one web hook to handle retry functionality.
If from the another side we’d have a possibility to specify GH App per Sonar Project, wet could manage those teams in much more flexible way and scaling will be not a problem.
we have got a bit different use case.
We have a single repository which has 3 kinda isolated folders, lets say backend, frontend, mobile.
Same structure in the sonar - 3 different projects.
There can be a pr where we touch only one module, or several at once.
Because of the slow builds those modules are built in parallel on different agents. Sonar check is done as part of the build script. Since we have only one Github application, the results of the checks are overlapped. Basically last one wins.
Welcome to our community !
It seems to me that your use case is similar to this one.
This is a subject that we plan to work on this year.