Use plugins as GitHub app instead of a user

[bartoszmajsak]

https://developer.github.com/apps/building-github-apps/

[MatousJobanek]

Benefits

As the first thing, I'd like to say why we would need to make the Ike plugins a GH app - what are the benefits:

• higher rate limit
• possibility to use checks tab
• easier way of adding a new repositories
• easier way of changing anything within the webhook settings (url, permissions, etc...)

Current state (obstacle)

The main obstacle is the logic that enables the particular plugins for specific repositories. Currently, it is done by plugins.yaml file. The hook reads this file every minute and when an event from the webhook is received then it checks the loaded configuration and decides which plugins the events should be dispatched to.

GH application way

The way the GH app would do it is a bit tricky. The apps can be in two modes - private or public. There is nothing in the middle and with the public mode we don't have any way to control the repositories/users/organization the app would be installed in. With private mode, the app can only be installed on the user or organization account of the application owner. In other words, we would need to go for the public mode or to become an administrator of all repositories.

Proposed solution

hook

As the first step, we would need to rewrite the hook. That wouldn't be so hard as we would need to change only the method for configuration loading and the server that checks and dispatches the events. We could implement our own with reusing the code from prow or try to provide a PR to test-infra project. Or maybe write our own implementation inspired by the current hook.

plugins per project

As there is no way to configure the GH app in UI, which means that it is not possible to easily enable/disable the plugins for particular projects, we would need to use the same solution as for example Travis does - configuration files. By default, all available plugins would be activated. If anyone would like to disable some of the plugins, he would need to add .ike-prow/plugins.yaml file to his repo, and disable the plugin there. That would also mean retrieving(downloading) the configuration file every time when a webhook event is received.

plugins.yaml replacement

At this point, we would need to decide if we want to open the application to the world or not.

• public - the public solution means that we activate the plugins for every project that has the application installed.
• rh-only - this mode would require some configuration file with a predefined list of organizations/users/repositories we want to activate the plugins for (eg. everything in fabric8 organization). When an event is received, then it would check if it matches the content of the config file or not.

Questions

So my questions are:

1. is there any reason why we shouldn't make the plugins public?
2. is there anything in the current hook implementation we would like to change?
3. if the answer to the first question is YES and to the second is NO, then do we really need to make plugins a GH app? Does it pay off?