Adding a plugin system for customization
Today more and more feature requests start to result in discussions about how and whether new features are implemented at all. In some cases where it seems to be only a small change from the view of a customer, this could become frustrating. Sometimes the arguments against a change are as simple as not to break the workflow of other customers or keeping GitLab simple.
As solution I'd like to propose the introduction of a plugin system to support customization. The plugin system could start in the following areas :
- selection of allowed merge request approvers (allowing to approve my own merge requests)
- integrating - external build servers (currently GitLab doesn't that there is a build server until a build status is sent)
- integrating - new issue trackers (support other systems like versionone, trac, etc.)
A plugin system could be used to solve the issue that some options are not interesting for certain people where as it's required by by others. The options will only appear/active if the related plugin is installed. I know designing a plugin system is not an easy task, since new problems will occur such as in which order ui contribution are show or when things are overlapping, however I think GitLab could benefit a lot from such a system. Just look at jenkins and eclipse, how much great contributions the community provides.
Define a API containing some interfaces/classes to be used for overwriting or extending behaviour:
- Allow to contribute widgets such as checkboxes and textboxes to the new merge request ui and project settings ui in order
- Allow to hook into the filtering of merge request approvers
In a simplest form a plugin could be just a bunch of ruby-files which can be uploaded by the admin. Containing an entry point for registering the code in GitLab.