>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.
On Tuesday, May 15, 2018 at 9:15:33 PM UTC+10, Oleg Nenashev wrote: > > +1 for deprecating Ruby Runtime if it's done via the JEP process. Although > it may be important for users, I see no way to maintain that. To soften the > impact we could make Ruby plugins available via a separate small update > center so that users can install them (at their own risk). > > Once/if JEP is accepted, heads-up announcement in the Blog Post may be > also reasonable. It would allow to get attention from contributors and > users who may want to contribute to migrating/replacing the plugins. Some > plugins already have equivalent features offered by existing plugins, and > such blog post could also pave the migration path. > > Gitlab Hook plugin is a problem for sure, but it's not that big in the > terms of code from what I see. Maybe we could reach out to the vendor and > ask whether they are interested to work on the port to Java. > > Best regards, > Oleg > > On Monday, May 14, 2018 at 5:37:41 PM UTC+2, Jesse Glick wrote: >> >> On Mon, May 14, 2018 at 10:04 AM, Daniel Beck <[email protected]> wrote: >> > ruby-runtime has caused quite some work for core maintainers >> >> I have personally spent a fair amount of time trying to deal with it; >> for example, writing what seems to have been the first acceptance test >> exercising any Ruby-based functionality, so as to demonstrate the >> effectiveness of a core workaround for a bug in this runtime. >> >> > WDYT? >> >> +1. From the perspective of Essentials I think we need to be willing >> to sacrifice some old stuff which was serving as a drag on >> productivity. For the case of GitLab hooks in particular, developer >> effort would be better spent enhancing the (Java-based) branch source >> plugin to react to SCM events without polling. >> >> I suppose this proposal would be best formalized as a “standards” JEP, >> though JEP-1 does not specifically mention feature or subsystem >> deprecation as a use case. >> > -- 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/c86ab441-d69d-4d4e-af87-4c58b52cb58b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
