Deprecating ruby-runtime

822 views
Skip to first unread message

Daniel Beck

unread,
May 14, 2018, 10:04:10 AM5/14/18
to Jenkins Developers
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

Jesse Glick

unread,
May 14, 2018, 11:37:41 AM5/14/18
to Jenkins Dev
On Mon, May 14, 2018 at 10:04 AM, Daniel Beck <m...@beckweb.net> 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.

Oleg Nenashev

unread,
May 15, 2018, 7:15:33 AM5/15/18
to Jenkins Developers
+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

Jesse Glick

unread,
May 15, 2018, 8:27:43 AM5/15/18
to Jenkins Dev
On Tue, May 15, 2018 at 7:15 AM, Oleg Nenashev <o.v.ne...@gmail.com> 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.

Owen B. Mehegan

unread,
May 15, 2018, 7:56:17 PM5/15/18
to Jenkins Developers
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.

Jesse Glick

unread,
May 16, 2018, 7:31:09 AM5/16/18
to Jenkins Dev
On Tue, May 15, 2018 at 7:56 PM, Owen B. Mehegan <omeh...@gmail.com> 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.

Owen Mehegan

unread,
May 16, 2018, 7:37:53 AM5/16/18
to jenkin...@googlegroups.com
The gitlab-plugin that I maintain is technically a trigger plugin, not an SCM plugin.

--
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 jenkinsci-dev+unsubscribe@googlegroups.com.
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.

Daniel Beck

unread,
May 16, 2018, 9:50:20 AM5/16/18
to jenkin...@googlegroups.com

> On 16. May 2018, at 01:56, Owen B. Mehegan <omeh...@gmail.com> 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.

Liam Newman

unread,
May 16, 2018, 6:01:13 PM5/16/18
to jenkin...@googlegroups.com
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. 

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F2972DC0-FE37-4FE0-8E2D-B487D6049467%40beckweb.net.

Oleg Nenashev

unread,
Jun 14, 2018, 7:08:20 PM6/14/18
to Jenkins Developers
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

Slide

unread,
Jun 14, 2018, 7:46:32 PM6/14/18
to jenkin...@googlegroups.com
Is there a benefit to having a template for deprecating plugins in general? Having a JEP for deprecation of plugins would be nice.

Daniel Beck

unread,
Jul 1, 2018, 6:52:46 AM7/1/18
to jenkin...@googlegroups.com

> On 15. Jun 2018, at 01:08, Oleg Nenashev <o.v.ne...@gmail.com> 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).

Oleg Nenashev

unread,
Aug 12, 2018, 7:59:33 PM8/12/18
to Jenkins Developers
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

Jesse Glick

unread,
Aug 13, 2018, 2:56:09 PM8/13/18
to Jenkins Dev
On Sun, Aug 12, 2018 at 7:59 PM Oleg Nenashev <o.v.ne...@gmail.com> 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.

Daniel Beck

unread,
Aug 13, 2018, 4:07:59 PM8/13/18
to jenkin...@googlegroups.com

> On 13. Aug 2018, at 01:59, Oleg Nenashev <o.v.ne...@gmail.com> 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.

Oleg Nenashev

unread,
Aug 16, 2018, 1:45:46 PM8/16/18
to Jenkins Developers
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

Jesse Glick

unread,
Aug 16, 2018, 3:28:37 PM8/16/18
to Jenkins Dev
On Thu, Aug 16, 2018 at 1:45 PM Oleg Nenashev <o.v.ne...@gmail.com> 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.

Daniel Beck

unread,
Aug 16, 2018, 3:45:33 PM8/16/18
to jenkin...@googlegroups.com

> On 16. Aug 2018, at 19:45, Oleg Nenashev <o.v.ne...@gmail.com> 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.

Oleg Nenashev

unread,
Aug 17, 2018, 7:40:03 AM8/17/18
to Jenkins Developers
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

Gavin Mogan

unread,
Apr 14, 2021, 12:34:37 PM4/14/21
to Jenkins Developers
So revisiting this really old ticket.

As i've been working on rewriting/improving the process of processing metadata to produce plugin documentation, I'm noticing we have a lot more legacy bad data than I expected. While I am handling it, I also want to try and improve things. As such, ruby runtime is going to be on my list to discuss.

Looking at the original list that db generated, all of them have not been released in at least 5 years (most are 7-9 years), including gitlab-hook which has huge security errors listed. I was certain at one point I saw ruby runtime being no longer supported in core but I can't find confirmation of that, so may have been thinking of this discussion.

So revisiting, Can we suspend distribution of these plugins now? take them out of update center, prevent new installs from happening. As stated in the earlier comments by Jesse, this wouldn't prevent existing installs from using them (although they probably don't work), but would prevent peoples installs from getting worse.

If the only blocker to doing so was writing up a blog post I can draft something and we can start the process of removing the support and plugins for ruby runtime

Gavin

Jesse Glick

unread,
Apr 14, 2021, 1:12:55 PM4/14/21
to Jenkins Dev

Mark Waite

unread,
Apr 14, 2021, 1:52:41 PM4/14/21
to Jenkins Developers
The ruby runtime plugin fails to load when running Jenkins with Java 11.  I think that is one more reason to discuss deprecation of the ruby-runtime plugin again.

The failure message is "unsupported Java version: 11":

2021-04-14 17:46:48.215+0000 [id=31]    INFO    ruby.RubyRuntimePlugin#start: Injecting JRuby into XStream
2021-04-14 17:46:48.451+0000 [id=31]    WARNING jenkins.model.Jenkins$5#runTask: Loading plugin ruby-runtime v0.12 (ruby-runtime) failed perhaps due to plugin dependency issues
java.lang.RuntimeException: unsupported Java version: 11
        at org.jruby.RubyInstanceConfig.initGlobalJavaVersion(RubyInstanceConfig.java:1674)
        at org.jruby.RubyInstanceConfig.<clinit>(RubyInstanceConfig.java:1387)
Caused: java.lang.ExceptionInInitializerError
        at org.jruby.embed.internal.AbstractLocalContextProvider.<init>(AbstractLocalContextProvider.java:42)
        at org.jruby.embed.internal.SingleThreadLocalContextProvider.<init>(SingleThreadLocalContextProvider.java:43)
        at org.jruby.embed.ScriptingContainer.getProviderInstance(ScriptingContainer.java:242)
        at org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:226)
        at org.jruby.embed.ScriptingContainer.<init>(ScriptingContainer.java:192)
        at org.kohsuke.stapler.jelly.jruby.JRubyFacet.<init>(JRubyFacet.java:65)
        at ruby.RubyRuntimePlugin.registerJRubyFacet(RubyRuntimePlugin.java:39)
        at ruby.RubyRuntimePlugin.start(RubyRuntimePlugin.java:30)
        at hudson.ClassicPluginStrategy.startPlugin(ClassicPluginStrategy.java:406)
        at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:395)
Caused: java.io.IOException: Failed to initialize
        at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:398)
        at hudson.PluginManager$2$1$1.run(PluginManager.java:551)
        at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
        at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
        at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
        at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
        at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
        at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:829)
2021-04-14 17:46:48.457+0000 [id=32]    SEVERE  jenkins.InitReactorRunner$1#onTaskFailed: Failed Loading plugin Rvm v0.6 (rvm)
java.io.IOException: Failed to load: Rvm (0.6)
 - Plugin is missing: ruby-runtime (0.12)
        at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:950)
        at hudson.PluginManager$2$1$1.run(PluginManager.java:550)
        at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
        at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
        at jenkins.model.Jenkins$5.runTask(Jenkins.java:1131)
        at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
        at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
        at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:829)
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$2 (file:/home/mwaite/tmp/JENKINS-65243/war/WEB-INF/lib/guice-4.0.jar) to method java.lang.ClassLoader.                                         defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release


Daniel Beck

unread,
Apr 14, 2021, 2:20:40 PM4/14/21
to Jenkins Developers
Thanks for resurrecting this!

> On 14. Apr 2021, at 18:34, 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
>
> I saw ruby runtime being no longer supported in core but I can't find confirmation of that, so may have been thinking of this discussion.

https://github.com/jenkinsci/jenkins/blob/6f2e7b0085e39d02a92312a57a5cf7f0b84dfc05/core/src/main/resources/jenkins/security/whitelisted-classes.txt#L172-L198 is still in and can be cleaned up once we decide to go forward (I think this is one of the changes the JEP refers to).

> So revisiting, Can we suspend distribution of these plugins now? take them out of update center, prevent new installs from happening. As stated in the earlier comments by Jesse, this wouldn't prevent existing installs from using them (although they probably don't work), but would prevent peoples installs from getting worse.
>
> If the only blocker to doing so was writing up a blog post I can draft something and we can start the process of removing the support and plugins for ruby runtime

Since the last time we discussed this (and I created the JEP), we added deprecation warning support to Jenkins 2.246 and newer, which is basically designed for such a case. This makes JEP-7 much cleaner to implement, because we now have good ways to inform users about it.

I'd start with a deprecation warning for ruby-runtime and all dependent plugins pointing to the JEP or this thread (or, if you want to write it up, a blog post), and if folks don't <s>complain</s> offer to take over ruby-runtime maintainership in large enough numbers, we can suspend a few weeks later, followed by core cleanup. WDYT?


Tim Jacomb

unread,
Apr 14, 2021, 2:30:14 PM4/14/21
to Jenkins Developers

I'd start with a deprecation warning for ruby-runtime and all dependent plugins pointing to the JEP or this thread (or, if you want to write it up, a blog post), and if folks don't <s>complain</s> offer to take over ruby-runtime maintainership in large enough numbers, we can suspend a few weeks later, followed by core cleanup. WDYT?
 +1

Mark Waite

unread,
Apr 14, 2021, 2:36:23 PM4/14/21
to jenkinsci-dev
On Wed, Apr 14, 2021 at 12:20 PM Daniel Beck <m...@beckweb.net> wrote:

Since the last time we discussed this (and I created the JEP), we added deprecation warning support to Jenkins 2.246 and newer, which is basically designed for such a case. This makes JEP-7 much cleaner to implement, because we now have good ways to inform users about it.

I'd start with a deprecation warning for ruby-runtime and all dependent plugins pointing to the JEP or this thread (or, if you want to write it up, a blog post), and if folks don't <s>complain</s> offer to take over ruby-runtime maintainership in large enough numbers, we can suspend a few weeks later, followed by core cleanup. WDYT?


+1 from me.
 

Oleg Nenashev

unread,
Apr 14, 2021, 2:45:48 PM4/14/21
to JenkinsCI Developers
I am +1 for depreciation. I would recommend to make an announcement blog about that with e.g. 1-month advance notice, but there is no reason to keep these plugins around. Ruby plugin stack is not maintainable without a full-time contributor, we should pick our battles

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFpo1yfG81wQYMUYp9vq3wFP%2BE40zA5cyAuZLYAQF83JQ%40mail.gmail.com.

Jesse Glick

unread,
Apr 14, 2021, 4:26:28 PM4/14/21
to Jenkins Dev
On Wed, Apr 14, 2021 at 2:20 PM Daniel Beck <m...@beckweb.net> wrote:
if folks don't offer to take over ruby-runtime maintainership

Given the overhead this subsystem has forced on core developers, I would be in favor of deprecating it even if there were someone willing to maintain it.

Jim Klimov

unread,
Apr 14, 2021, 10:39:42 PM4/14/21
to Oleg Nenashev, JenkinsCI Developers
><https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFpo1yfG81wQYMUYp9vq3wFP%2BE40zA5cyAuZLYAQF83JQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>

I believe there were plugins depending on it, that got me to have to pick java8 explicitly on one system. I think gitlab-plugin might be it.

Jim

--
Typos courtesy of K-9 Mail on my Android

Owen Mehegan

unread,
Apr 14, 2021, 10:55:12 PM4/14/21
to jenkin...@googlegroups.com
gitlab-plugin doesn't depend on it, but gitlab-hook plugin does. It has been unmaintained for 5 years and functionality is replaced by gitlab-plugin and gitlab-branch-source.

Baptiste Mathus

unread,
Apr 15, 2021, 10:14:01 AM4/15/21
to Jenkins Developers
+1 for deprecating this. The Jenkins community should invest its time more into the future than these components that are lacking any kind of maintainership.

Cheers  

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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAHtcACEF8CtS5%2Bmd2WbipJSt0S9EHhp_ZJ96ZQ30KgTqXm4%3DEg%40mail.gmail.com.

Gavin Mogan

unread,
Apr 15, 2021, 10:38:57 PM4/15/21
to Jenkins Developers

Would love some ideas on workarounds.

I'll have a PR ready for update-center before may 15th.

Oleg Nenashev

unread,
Apr 16, 2021, 6:09:11 AM4/16/21
to Jenkins Developers
Thanks Gavin for the announcement draft! It looks great, and I plan to submit a few suggestions to improve it.

Regarding the process... Should we also add heads-up about removing the JEP-200 Ruby Runtime exceptions and XStream converters from the Jenkins core (source)? It is a reasonable next step, but it will nuke plugin users on the newer Jenkins cores. IMHO we should set a grace period, e.g. announce this change with a 6-month advance so that users have an opportunity to migrate to other plugins. In such a case, they may also benefit from an administrative monitor warning them about the breaking change (it would be a nice engine in general for deprecations).

BR, Oleg

Jesse Glick

unread,
Apr 16, 2021, 10:00:30 AM4/16/21
to Jenkins Dev
On Fri, Apr 16, 2021 at 6:09 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
[Regarding] removing the JEP-200 Ruby Runtime exceptions and XStream converters from the Jenkins core […] we should set a grace period, e.g. announce this change with a 6-month advance so that users have an opportunity to migrate to other plugins.

I do not see any need to wait that long. Just do it and announce it applies to the next weekly. The next LTS upgrade guide will mention this of course. Users have the “opportunity” to migrate to other plugins whenever they want, or simply decline to update Jenkins core.

Gavin Mogan

unread,
Apr 16, 2021, 12:49:05 PM4/16/21
to Jenkins Developers
There's only a single python plugin, so I think we should include python in this announcement too


the install shield plugin only has 200 installs and I suspect it also won't work right in java 11?

Gavin

--
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 jenkinsci-de...@googlegroups.com.

Oleg Nenashev

unread,
Apr 16, 2021, 1:18:52 PM4/16/21
to JenkinsCI Developers
It might work on Java 11, bit I see no much reason in even trying. If we drop the Ruby ecosystem, Python should go as well IMHO

Oleg Nenashev

unread,
Apr 21, 2021, 3:00:03 AM4/21/21
to Jenkins Developers
I added the topic to the Governance meeting agenda just in case more discussion is needed.
https://github.com/jenkins-infra/jenkins.io/pull/4256 is almost ready to go IMHO, but, as Daniel Beck commented, we also need to do something about JEP-7: https://github.com/jenkinsci/jep/tree/master/jep/7 . I will try contributing to that if my time allows

BR, Oleg


Oleg Nenashev

unread,
Apr 27, 2021, 5:10:43 AM4/27/21
to JenkinsCI Developers
JEP update is ready for review: https://github.com/jenkinsci/jep/pull/356 . There are some changes in the rollout plan we discussed with Daniel Beck on Monday, some reviews and alignment might be required



Oleg Nenashev

unread,
May 8, 2021, 6:05:24 PM5/8/21
to Jenkins Developers
Hi Gavin,

Did you have a chance to review https://github.com/jenkinsci/jep/pull/356 ?
I think the change is stuck, and it would be great to get it over the line

Best regards,
Oleg
Reply all
Reply to author
Forward
0 new messages