• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • Jenkins 2.91, ruby-runtime 0.12, Rvm 0.6, rbenv plugin 0.0.17, Linux HOSTNAME 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

      After updating from 2.90 to 2.91 we are experiencing the following issue on Jobs which require either rbenv or rvm:

      As soon as enabling rvm and setting it to Ruby 2.3.1 we get the following error in the console log

      FATAL: (NoMethodError) undefined method `<<' for #<Jenkins::Plugin::OpaqueJavaObject:0x27ac28ca>
       org.jruby.exceptions.RaiseException: (NoMethodError) undefined method `<<' for #<Jenkins::Plugin::OpaqueJavaObject:0x27ac28ca>
       at RUBY.setup(/virtual/jenkins/plugins/rvm/WEB-INF/classes/models/rvm_wrapper.rb:33)
       at RUBY.setUp(/virtual/jenkins/plugins/rvm/WEB-INF/classes/vendor/gems/bundler/../gems/jenkins-plugin-runtime-0.2.3/lib/jenkins/model/environment_proxy.rb:8)

      With ebenv we get a very similar issue:

      FATAL: (NoMethodError) undefined method `<<' for #<Jenkins::Plugin::OpaqueJavaObject:0x15176737>
      org.jruby.exceptions.RaiseException: (NoMethodError) undefined method `<<' for #<Jenkins::Plugin::OpaqueJavaObject:0x15176737>
      	at RUBY.install!(/virtual/jenkins/plugins/rbenv/WEB-INF/classes/lib/rbenv.rb:46)
      	at RUBY.setup!(/virtual/jenkins/plugins/rbenv/WEB-INF/classes/lib/rbenv.rb:20)
      	at RUBY.setup(/virtual/jenkins/plugins/rbenv/WEB-INF/classes/models/rbenv_wrapper.rb:65)
      	at RUBY.setUp(/virtual/jenkins/plugins/rbenv/WEB-INF/classes/vendor/gems/bundler/../gems/jenkins-plugin-runtime-0.2.3/lib/jenkins/model/environment_proxy.rb:8)

       
      Current workaround is to downgrade to 2.90, which obviously is not a good solution.

          [JENKINS-48116] Jenkins 2.91 breaks builds which require Ruby

          Jesse Glick added a comment - - edited

          Filed a PR switching to StreamTaskListener (more correct anyway, to the extent I understand this craziness), but as previously mentioned, to actually release the fix would apparently require 20 different repositories (acc. to fgrep ruby-runtime */*.pluginspec) to be patched and then released.

          Jesse Glick added a comment - - edited Filed a PR switching to StreamTaskListener (more correct anyway, to the extent I understand this craziness), but as previously mentioned, to actually release the fix would apparently require 20 different repositories (acc. to fgrep ruby-runtime */*.pluginspec ) to be patched and then released.

          Daniel Beck added a comment -

          There are just five plugins updated in the last two years or with at least 1000 installations. If it weren't for gitlab-hook's 8000 installs I'd just recommend we blacklist all of this mess for being broken.

          Daniel Beck added a comment - There are just five plugins updated in the last two years or with at least 1000 installations. If it weren't for gitlab-hook's 8000 installs I'd just recommend we blacklist all of this mess for being broken.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/org/jenkinsci/test/acceptance/plugins/rvm/Rvm.java
          src/test/java/plugins/RvmPluginTest.java
          http://jenkins-ci.org/commit/acceptance-test-harness/3b8f705d3e9789932d2ab428013c5fd428912900
          Log:
          JENKINS-48116 Smoke test for the rvm plugin.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/test/acceptance/plugins/rvm/Rvm.java src/test/java/plugins/RvmPluginTest.java http://jenkins-ci.org/commit/acceptance-test-harness/3b8f705d3e9789932d2ab428013c5fd428912900 Log: JENKINS-48116 Smoke test for the rvm plugin.

          Code changed in jenkins
          User: Oliver Gondža
          Path:
          src/main/java/org/jenkinsci/test/acceptance/plugins/rvm/Rvm.java
          src/test/java/plugins/RvmPluginTest.java
          http://jenkins-ci.org/commit/acceptance-test-harness/76b759b39891c348fe937d6028b4d0bc5fdbd39a
          Log:
          Merge pull request #383 from jglick/rvm

          JENKINS-48116 Smoke test for the rvm plugin

          Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/66229eecdfcf...76b759b39891

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oliver Gondža Path: src/main/java/org/jenkinsci/test/acceptance/plugins/rvm/Rvm.java src/test/java/plugins/RvmPluginTest.java http://jenkins-ci.org/commit/acceptance-test-harness/76b759b39891c348fe937d6028b4d0bc5fdbd39a Log: Merge pull request #383 from jglick/rvm JENKINS-48116 Smoke test for the rvm plugin Compare: https://github.com/jenkinsci/acceptance-test-harness/compare/66229eecdfcf...76b759b39891

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/hudson/util/AbstractTaskListener.java
          core/src/main/java/hudson/util/LogTaskListener.java
          core/src/main/java/hudson/util/StreamTaskListener.java
          http://jenkins-ci.org/commit/jenkins/60085a0f10409265aa6d028ed5ae9a3b7b9e30f2
          Log:
          JENKINS-48116 - Restrore AbstractTaskListener binary compatibility in the core.

          Since we have the confirmed regression due to the binary compatibility change, I think we need to restore the compatibility.
          OTOH, I restricted the class, so all users will be forced to stop using it when they updgrade the core.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/hudson/util/AbstractTaskListener.java core/src/main/java/hudson/util/LogTaskListener.java core/src/main/java/hudson/util/StreamTaskListener.java http://jenkins-ci.org/commit/jenkins/60085a0f10409265aa6d028ed5ae9a3b7b9e30f2 Log: JENKINS-48116 - Restrore AbstractTaskListener binary compatibility in the core. Since we have the confirmed regression due to the binary compatibility change, I think we need to restore the compatibility. OTOH, I restricted the class, so all users will be forced to stop using it when they updgrade the core.

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/hudson/util/AbstractTaskListener.java
          core/src/main/java/hudson/util/LogTaskListener.java
          core/src/main/java/hudson/util/StreamTaskListener.java
          http://jenkins-ci.org/commit/jenkins/f33506f4f6b428a49aeef4574df00ce483a65257
          Log:
          Merge pull request #3154 from oleg-nenashev/bug/JENKINS-48116

          JENKINS-48116 - Restore AbstractTaskListener binary compatibility in the core.

          Compare: https://github.com/jenkinsci/jenkins/compare/b431eb422a8f...f33506f4f6b4

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/hudson/util/AbstractTaskListener.java core/src/main/java/hudson/util/LogTaskListener.java core/src/main/java/hudson/util/StreamTaskListener.java http://jenkins-ci.org/commit/jenkins/f33506f4f6b428a49aeef4574df00ce483a65257 Log: Merge pull request #3154 from oleg-nenashev/bug/ JENKINS-48116 JENKINS-48116 - Restore AbstractTaskListener binary compatibility in the core. Compare: https://github.com/jenkinsci/jenkins/compare/b431eb422a8f...f33506f4f6b4

          Oleg Nenashev added a comment -

          The fix has been integrated towards 2.92

          Oleg Nenashev added a comment - The fix has been integrated towards 2.92

          Daniel Beck added a comment -

          oleg_nenashev Do we need separate issues for plugins to migrate off this ticking time bomb? We can't let core be shackled to faulty assumptions from 5 years ago.

          Daniel Beck added a comment - oleg_nenashev Do we need separate issues for plugins to migrate off this ticking time bomb? We can't let core be shackled to faulty assumptions from 5 years ago.

          Oleg Nenashev added a comment -

          danielbeck I think we "just" need an EPIC for creating "ruby-runtime-api" plugin and then migrating the dependent plugins. And yeah, we need a hero who is ready to work on it.

          Oleg Nenashev added a comment - danielbeck I think we "just" need an EPIC for creating "ruby-runtime-api" plugin and then migrating the dependent plugins. And yeah, we need a hero who is ready to work on it.

          oleg_nenashev @all thanks for your efforts on this, very much appreciated!

          Martin Kim Dung-Pham added a comment - oleg_nenashev @all thanks for your efforts on this, very much appreciated!

            oleg_nenashev Oleg Nenashev
            martinkim Martin Kim Dung-Pham
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: