Deprecating ruby-runtime

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecating ruby-runtime

Daniel Beck
ruby-runtime is a plugin that allows Jenkins plugins to be implemented in Ruby. It has quite a number of problems:

* The source code situation is a mess, with two separate repositories.
        https://github.com/jenkinsci/ruby-runtime-plugin/pull/6#issuecomment-383842017
        https://github.com/jenkinsci/ruby-runtime-plugin/
        https://github.com/jenkinsci/jenkins.rb/tree/master/java-runtime

* It is unmaintained, with the latest release (0.12) in 2013. While the changelog claims that 0.13 was released in 2016, it's not actually available on update sites. The last real activity seems to have happened around 2014.
        http://plugins.jenkins.io/ruby-runtime

* It caused problem after a core update a few months back due to a faulty assumption. As the plugin is unmaintained, and parts get packaged in dependent plugins (i.e. fixing ruby-runtime isn't enough), we had to revert part of the core change, or accept that ruby-runtime based plugins remain broken until they all _individually_ get updated.
        https://jenkins.io/changelog/#v2.92
        https://issues.jenkins-ci.org/browse/JENKINS-48116
        https://github.com/jenkinsci/jenkins/pull/3154
        https://issues.jenkins-ci.org/browse/JENKINS-48116?focusedCommentId=320469&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-320469

* It required extensive whitelisting in core to achieve JEP-200 compatibility due to the JRuby glue.
        https://github.com/jenkinsci/jenkins/blob/91e1cf2d3e0fa1c4766c62f2db54cd3a28cd9d32/core/src/main/resources/jenkins/security/whitelisted-classes.txt#L171...L197

ruby-runtime is used by 22 other plugins as a dependency. Most of them appear to not be actively maintained, not having received a new release in several years. Only three were released in the past two years and/or have more than 1000 installs.

https://plugins.jenkins.io/buddycloud was last released Jun 05, 2014 (1 install)
https://plugins.jenkins.io/capitomcat was last released Feb 17, 2015 (980 installs)
https://plugins.jenkins.io/chef was last released Aug 29, 2015 (451 installs)
https://plugins.jenkins.io/ci-skip was last released Dec 23, 2013 (406 installs)
https://plugins.jenkins.io/commit-message-trigger-plugin was last released Sep 30, 2014 (272 installs)
https://plugins.jenkins.io/cucumber was last released Mar 13, 2013 (493 installs)
https://plugins.jenkins.io/devstack was last released Sep 17, 2012 (18 installs)
https://plugins.jenkins.io/git-notes was last released Apr 23, 2012 (692 installs)
https://plugins.jenkins.io/gitlab-hook was last released Apr 17, 2016 (9667 installs)
https://plugins.jenkins.io/ikachan was last released Jun 04, 2012 (12 installs)
https://plugins.jenkins.io/jenkinspider was last released Jun 19, 2015 (12 installs)
https://plugins.jenkins.io/mysql-job-databases was last released Sep 20, 2014 (233 installs)
https://plugins.jenkins.io/pathignore was last released Nov 18, 2011 (331 installs)
https://plugins.jenkins.io/perl was last released Mar 07, 2013 (178 installs)
https://plugins.jenkins.io/perl-smoke-test was last released Sep 26, 2014 (30 installs)
https://plugins.jenkins.io/pry was last released May 31, 2012 (80 installs)
https://plugins.jenkins.io/pyenv was last released Aug 06, 2014 (903 installs)
https://plugins.jenkins.io/rbenv was last released Apr 18, 2016 (983 installs)
https://plugins.jenkins.io/rvm was last released Aug 10, 2016 (2261 installs)
https://plugins.jenkins.io/singleuseslave was last released May 07, 2015 (131 installs)
https://plugins.jenkins.io/travis-yml was last released Nov 13, 2016 (434 installs)
https://plugins.jenkins.io/yammer was last released Jul 19, 2013 (129 installs)

The by far most popular plugin based on ruby-runtime is gitlab-hook at just under 10k installs. It is part of last week's security advisory, as its maintainer published a fix for a (fairly minor, but still) security vulnerability two years ago, but never actually released it, or informed the security team that he worked on it in public, so can be considered not actively maintained.
https://jenkins.io/security/advisory/2018-05-09/#SECURITY-263
https://github.com/jenkinsci/gitlab-hook-plugin/commit/8e127c3ee8fb164acbf9f73530215f788b531033

I don't think any of the above problems are inherently unrecoverable, but unless somebody is ready to take ownership of ruby-runtime, and fixes its problems, my proposal is to remove ruby-runtime from distribution, and announce its deprecation. Distribution of dependent plugins would necessarily be suspended as well, until reimplemented in Java, similar to other plugins with unsatisfiable dependencies.

Generally there's no reason for something to be removed from distribution just because it doesn't work well. But ruby-runtime has caused quite some work for core maintainers, as the above references show, and wasted time better spent elsewhere. I think it's only a matter of time until things break in ways not easily recoverable, and the longer we wait, the more painful it will be.

WDYT?

Daniel

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6797DF59-E37F-4361-B007-9F60A856E1FB%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Jesse Glick-4
On Mon, May 14, 2018 at 10:04 AM, Daniel Beck <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2d_VemZL2ZqB4BSrmHDByQqcU1C2%2Buja6srwwWMaOieQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Oleg Nenashev
+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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="cxk8O8F3BwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">m...@...> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3ac4642d-cee1-4b02-85d7-ef4d1d2d2aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Jesse Glick-4
On Tue, May 15, 2018 at 7:15 AM, Oleg Nenashev <[hidden email]> wrote:
> we could make Ruby plugins available via a separate small update
> center

There is no precedent for this and I think it would be more confusing
than helpful.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0UD5AMgep7zmdgmn7RuA9-3i2rg0Y15yNi7UQdFayiBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Owen Mehegan-2
In reply to this post by Oleg Nenashev
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 <[hidden email]> 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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Jesse Glick-4
On Tue, May 15, 2018 at 7:56 PM, Owen B. Mehegan <[hidden email]> wrote:
> 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 thought all SCM plugins had this system? `/git/notifyCommit`,
`/github-webhook/`, `/mercurial/notifyCommit`,
`/subversion/:UUID/notifyCommit`, etc.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3mE-j0q_WvE1CPb-m%2BUWaS%2Bv3tXBV-cGmM2e11Qgj7vQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Owen Mehegan-2
The gitlab-plugin that I maintain is technically a trigger plugin, not an SCM plugin.

On May 16, 2018 9:31 PM, "Jesse Glick" <[hidden email]> wrote:
On Tue, May 15, 2018 at 7:56 PM, Owen B. Mehegan <[hidden email]> wrote:
> 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 thought all SCM plugins had this system? `/git/notifyCommit`,
`/github-webhook/`, `/mercurial/notifyCommit`,
`/subversion/:UUID/notifyCommit`, etc.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/Ve0fqAud3Mk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3mE-j0q_WvE1CPb-m%2BUWaS%2Bv3tXBV-cGmM2e11Qgj7vQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAHtcACE%2BFy%2BZohvzQAniRPay65O6zewbPKQsJLkS5LhYAAj%3DsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Daniel Beck
In reply to this post by Owen Mehegan-2

> On 16. May 2018, at 01:56, Owen B. Mehegan <[hidden email]> 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 [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Liam Newman
I agree with Oleg.  Let's do a JEP on this to plan and implement the deprecation, since it is a breaking change for anyone one using these plugins.
-L. 

On Wed, May 16, 2018 at 6:50 AM Daniel Beck <[hidden email]> wrote:

> On 16. May 2018, at 01:56, Owen B. Mehegan <[hidden email]> 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 [hidden email].
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNyUg8LGArr4RrKRYry71mg9sqsmAfy2U-Q80AQ058pN6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Oleg Nenashev
JEP is here: https://github.com/jenkinsci/jep/tree/master/jep/7
before the JEP is accepted, it would be great to see a rollout plan which is currently missing in the JEP.

BR, Oleg

P.S: I think it worth including "Rollout Plan" to the standard template

On Thursday, May 17, 2018 at 12:01:13 AM UTC+2, Liam Newman wrote:
I agree with Oleg.  Let's do a JEP on this to plan and implement the deprecation, since it is a breaking change for anyone one using these plugins.
-L. 

On Wed, May 16, 2018 at 6:50 AM Daniel Beck <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2EVrpZE-CQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">m...@...> wrote:

> On 16. May 2018, at 01:56, Owen B. Mehegan <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2EVrpZE-CQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">omeh...@...> 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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="2EVrpZE-CQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/F2972DC0-FE37-4FE0-8E2D-B487D6049467%40beckweb.net" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/F2972DC0-FE37-4FE0-8E2D-B487D6049467%40beckweb.net&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/F2972DC0-FE37-4FE0-8E2D-B487D6049467%40beckweb.net&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/F2972DC0-FE37-4FE0-8E2D-B487D6049467%40beckweb.net.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/46a5c0d2-5e30-496f-a24e-255cea1a7075%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

slide
Is there a benefit to having a template for deprecating plugins in general? Having a JEP for deprecation of plugins would be nice.

On Thu, Jun 14, 2018, 16:08 Oleg Nenashev <[hidden email]> wrote:
before the JEP is accepted, it would be great to see a rollout plan which is currently missing in the JEP.

BR, Oleg

P.S: I think it worth including "Rollout Plan" to the standard template

On Thursday, May 17, 2018 at 12:01:13 AM UTC+2, Liam Newman wrote:
I agree with Oleg.  Let's do a JEP on this to plan and implement the deprecation, since it is a breaking change for anyone one using these plugins.
-L. 

On Wed, May 16, 2018 at 6:50 AM Daniel Beck <[hidden email]> wrote:

> On 16. May 2018, at 01:56, Owen B. Mehegan <[hidden email]> 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 [hidden email].

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/46a5c0d2-5e30-496f-a24e-255cea1a7075%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVe4vQBZq4VX-GyVDeYuyfDmLP2o0%2Bc9pTbg-uX5TNGTsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Daniel Beck
In reply to this post by Oleg Nenashev

> On 15. Jun 2018, at 01:08, Oleg Nenashev <[hidden email]> wrote:
>
> before the JEP is accepted, it would be great to see a rollout plan which is currently missing in the JEP.
>

I don't understand this request.

It'll take me 15 minutes to implement the specification if I don't need to wait for (with JEP fairly redundant) PR reviews. All actions listed are very trivial, with the potential exception of identifying undoing workarounds in core (and those can be done whenever we get around to them).

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/7F12E198-E651-4A1C-A296-2A2B9F2EBBAD%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.