Deprecating ruby-runtime

classic Classic list List threaded Threaded
19 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.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Oleg Nenashev
Sorry, I have missed my action item in this thread. I am really afraid of the "it will take 15 minutes to implement the specification" statement. Sure, it's just 15 minutes if we agree that approximately 5% of Jenkins installations get seriously impacted by the change and lose critical plugins without preliminary announcement. It is a big number of users whom we do not want to lose IMO. That's why I requested the rollout plan so that we are more careful with delivering the change.

Just to clarify the request, I would expect the following...
  1. Do you plan to create a blogpost announcing the change in advance (e.g. 2 weeks before the plugins are removed)?
  2. Would you add some administrative warnings directly to the Jenkins instances using plugins? Itcan be implemented via a security announcement with existing tools AFAICT
  3. Do you plan to notify plugin maintainers in advance so that they have a chance to react before the plugins disappear from the main UC?
  4. Do you plan to offer workarounds so that users can keep using the plugins for a while (e.g. by downloading from the experimental UC or so)?
One may say that it is enough to just announce a change in the weekly changelog and then reference it in upgrade guidelines. I am not 100% sure about that, because, should a security release happen at the same timeframe, users may be dead in water if they depend on the main update centers (not recommended for paranoid setups, I'd guess).

Once again, I totally support deprecating Ruby Runtime and I appreciate that you drive the effort.  But we just need to be careful with that to avoid major breaking precedents.

BR, Oleg

On Sunday, July 1, 2018 at 12:52:46 PM UTC+2, Daniel Beck wrote:

> On 15. Jun 2018, at 01:08, Oleg Nenashev <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="tnDoyEw_AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">o.v.ne...@...> 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/8f5a20c4-1443-46a3-bd41-2d0fdd17de61%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 Sun, Aug 12, 2018 at 7:59 PM Oleg Nenashev <[hidden email]> wrote:
> Do you plan to create a blogpost announcing the change in advance

Why? People who already have the plugins installed are unaffected,
unless and until we remove core workarounds for them—which is
something that belongs in the weekly release notes (and subsequently
in an LTS upgrade guide).

> Would you add some administrative warnings directly to the Jenkins instances using plugins?

Yes I think we should do that.

> Do you plan to notify plugin maintainers in advance

Consider this thread that notification.

> Do you plan to offer workarounds so that users can keep using the plugins for a while

You mean, so that _new_ users can _install_ the plugins? I would say no.

> should a security release happen at the same timeframe, users may be dead in water

If they are simply getting an LTS update with core security patches,
they are unaffected.

--
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/CANfRfr2KPwhpvEYqOLuRX3LEOOjX_XLjjpaw35P1gHUSypobYw%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 13. Aug 2018, at 01:59, Oleg Nenashev <[hidden email]> wrote:
>
> Sorry, I have missed my action item in this thread. I am really afraid of the "it will take 15 minutes to implement the specification" statement. Sure, it's just 15 minutes if we agree that approximately 5% of Jenkins installations get seriously impacted by the change and lose critical plugins without preliminary announcement.

… once they upgrade. We're not deleting plugin HPIs or other data from their local disks.

> Just to clarify the request, I would expect the following...
> • Do you plan to create a blogpost announcing the change in advance (e.g. 2 weeks before the plugins are removed)?

No. Changelogs (and in the case of LTS, upgrade guides) inform users about changes to Jenkins.

> • Would you add some administrative warnings directly to the Jenkins instances using plugins? Itcan be implemented via a security announcement with existing tools AFAICT

No, as the warnings UI is specifically labeled 'security'.

> • Do you plan to notify plugin maintainers in advance so that they have a chance to react before the plugins disappear from the main UC?

As Jesse wrote, this thread and the JEP are the notification.

> • Do you plan to offer workarounds so that users can keep using the plugins for a while (e.g. by downloading from the experimental UC or so)?

The workaround is to not throw away what downloads they already have, or especially savvy users can download from Artifactory -- similar to April 2017 when we delisted numerous plugins.

> One may say that it is enough to just announce a change in the weekly changelog and then reference it in upgrade guidelines. I am not 100% sure about that, because, should a security release happen at the same timeframe, users may be dead in water if they depend on the main update centers (not recommended for paranoid setups, I'd guess).

OK, so we'll schedule the core change (the part I specifically excluded from "15 minutes") to shortly _after_ a scheduled core security fix. Easy enough to do.

--
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/405E1B2D-1173-4118-A06A-427DFD045763%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Oleg Nenashev
You mean, so that _new_ users can _install_ the plugins? I would say no.

How would you define a "new" user in the new configuration-as-code world? If somebody uses official Jenkins Docker image with plugins.txt, the plugins will fail to install when you rebuild the image after the change gets deployed. And it is a pretty popular approach nowadays. Plugin installation features in JCasC 1.0 RC would be also affected AFAICT.

… once they upgrade. We're not deleting plugin HPIs or other data from their local disks.

same as above

BR, Oleg
 
On Monday, August 13, 2018 at 10:07:59 PM UTC+2, Daniel Beck wrote:

> On 13. Aug 2018, at 01:59, Oleg Nenashev <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="CtC40kGgDQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">o.v.ne...@...> wrote:
>
> Sorry, I have missed my action item in this thread. I am really afraid of the "it will take 15 minutes to implement the specification" statement. Sure, it's just 15 minutes if we agree that approximately 5% of Jenkins installations get seriously impacted by the change and lose critical plugins without preliminary announcement.

… once they upgrade. We're not deleting plugin HPIs or other data from their local disks.

> Just to clarify the request, I would expect the following...
>         • Do you plan to create a blogpost announcing the change in advance (e.g. 2 weeks before the plugins are removed)?

No. Changelogs (and in the case of LTS, upgrade guides) inform users about changes to Jenkins.

>         • Would you add some administrative warnings directly to the Jenkins instances using plugins? Itcan be implemented via a security announcement with existing tools AFAICT

No, as the warnings UI is specifically labeled 'security'.

>         • Do you plan to notify plugin maintainers in advance so that they have a chance to react before the plugins disappear from the main UC?

As Jesse wrote, this thread and the JEP are the notification.

>         • Do you plan to offer workarounds so that users can keep using the plugins for a while (e.g. by downloading from the experimental UC or so)?

The workaround is to not throw away what downloads they already have, or especially savvy users can download from Artifactory -- similar to April 2017 when we delisted numerous plugins.

> One may say that it is enough to just announce a change in the weekly changelog and then reference it in upgrade guidelines. I am not 100% sure about that, because, should a security release happen at the same timeframe, users may be dead in water if they depend on the main update centers (not recommended for paranoid setups, I'd guess).

OK, so we'll schedule the core change (the part I specifically excluded from "15 minutes") to shortly _after_ a scheduled core security fix. Easy enough to do.

--
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/fc0d1b3b-f1d9-46da-87e1-3df1419d7d84%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 Thu, Aug 16, 2018 at 1:45 PM Oleg Nenashev <[hidden email]> wrote:
> If somebody uses official Jenkins Docker image with plugins.txt, the plugins will fail to install when you rebuild the image after the change gets deployed.

I am OK with that. If they really want it, they can get it from Artifactory.

I am not even sure this is really true—IIUC blacklisting a plugin just
means it does not appear in `update-center.actual.json`, but the
`http://updates.jenkins.io/download/plugins/$name/$version/$name.hpi`
link should still work, right? And that is all you should be relying
on from JCasC. If some Docker build process relies on UC JSON, it is
already broken because it is not actually locking down anything, and
you could get a different image every time you build.

--
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/CANfRfr0a1QpjOmZyxUNjNdddvGTAiiDst5hJkUHPJSnROzovCw%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 16. Aug 2018, at 19:45, Oleg Nenashev <[hidden email]> wrote:
>
>> You mean, so that _new_ users can _install_ the plugins? I would say no.
>
> How would you define a "new" user in the new configuration-as-code world? If somebody uses official Jenkins Docker image with plugins.txt, the plugins will fail to install when you rebuild the image after the change gets deployed. And it is a pretty popular approach nowadays. Plugin installation features in JCasC 1.0 RC would be also affected AFAICT.

As of last count, 111 installs of CasC plugin. I'd be _very_ surprised if this ended up affecting more than 5 systems total.

And while this isn't the only approach to configuration-as-code, people should not expect us to continue distributing plugins indefinitely after we blacklisted the likes of Scriptler, Build Flow, Copy to Slave, or Perforce.

Notably, update sites only have the newest release, which isn't suitable for C-as-C anyway, so I expect the more stable approaches to use our Maven repo anyway -- which will not be affected.

Running one's own Maven repo has been an important best practice for a long time. With C-as-C, running one's own update site should be similar.

I will amend the JEP to record this concern and the answers. I don't think we need to change anything about the chosen approach.

--
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/C1E30C7F-1CC2-4A33-853F-0568A9A818C4%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating ruby-runtime

Oleg Nenashev
Hi Daniel,

Thanks for the amendment!
Would it be also possible to add an "Announcement" section to reasoning and explicitly document why proposals (blogpost, administrative warning, direct maintainer notification) are rejected?

I still disagree with the user notification approach taken in this proposal, and I believe we should do the best possible effort to notify users.
Spending 1 hour to write a blogpost with heads-up and workaround guidelines (and invitations to contribute) is the most obvious way to do that.
I do not understand why there is so much resistance about that.

CCing all known plugin maintainers in this thread is another obvious way to make them aware of the thread. We cannot expect that any plugin maintainer carefully reads every thread in the mailing list.

"Scriptler, Build Flow, Copy to Slave, or Perforce."
 
I do not buy that justification for JEP-7. All these plugins have been depublished due to security reasons, so there was no way to properly notify users in advance. But even in such case, the users know about the incoming security release in advance so they can prepare to mitigate breaking changes. Maintainers also got directly contacted, and they acknowledged the action. Here you propose to depublish a bunch of non-healthy-but-operational plugins, and the proposed notification process is "let's just do that, they should have read mailing lists". And there are low-cost ways to let users know in advance and to soften the change. I cannot agree with such approach, sorry.

Best regards,
Oleg


On Thursday, August 16, 2018 at 9:45:33 PM UTC+2, Daniel Beck wrote:

> On 16. Aug 2018, at 19:45, Oleg Nenashev <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="KQJBesEPEAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">o.v.ne...@...> wrote:
>
>> You mean, so that _new_ users can _install_ the plugins? I would say no.
>
> How would you define a "new" user in the new configuration-as-code world? If somebody uses official Jenkins Docker image with plugins.txt, the plugins will fail to install when you rebuild the image after the change gets deployed. And it is a pretty popular approach nowadays. Plugin installation features in JCasC 1.0 RC would be also affected AFAICT.

As of last count, 111 installs of CasC plugin. I'd be _very_ surprised if this ended up affecting more than 5 systems total.

And while this isn't the only approach to configuration-as-code, people should not expect us to continue distributing plugins indefinitely after we blacklisted the likes of Scriptler, Build Flow, Copy to Slave, or Perforce.

Notably, update sites only have the newest release, which isn't suitable for C-as-C anyway, so I expect the more stable approaches to use our Maven repo anyway -- which will not be affected.

Running one's own Maven repo has been an important best practice for a long time. With C-as-C, running one's own update site should be similar.

I will amend the JEP to record this concern and the answers. I don't think we need to change anything about the chosen approach.

--
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/34ef7c17-96ac-469e-acc2-e1ceb74c92ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.