> On 16. May 2018, at 01:56, Owen B. Mehegan <[email protected]> wrote: > > From my perspective as maintainer of the "competing" GitLab plugin, there is > one primary feature that the GitLab Hook plugin has which the GitLab Plugin > does not. It has a single REST endpoint which all GitLab repos can point to. > When GitLab POSTs to this, the plugin looks at the GitLab repo in the payload > and then triggers all Jenkins jobs which clone that repo. I find this feature > annoying, but some users prefer it, and I think this accounts for a lot of > that plugin's users. The GitLab Plugin has an open PR which will allow users > to create one global webhook endpoint to use, but they will still need to > "subscribe" Jenkins jobs to that endpoint if they want them to be built when > it receives a POST. I think the explicit/opinionated approach here leads to a > better development process, but not everyone agrees.
Nobody is claiming that it's not useful. In fact, gitlab-hook so far was the major motivator (at least for me) to keep ruby-runtime running, despite its problems. However, gitlab-hook plugin is unmaintained (for two years now), the runtime it's based on is even more unmaintained (five years), and we're experiencing problems inhibiting core development because of it. Realistically, the alternative here is to just not care about ruby-runtime related problems introduced by further core development. This would take care of this problem quite naturally. I'd still prefer to be explicit about it. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F2972DC0-FE37-4FE0-8E2D-B487D6049467%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
