• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core, ruby-runtime-plugin
    • 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

          Martin Kim Dung-Pham created issue -

          Oleg Nenashev added a comment -

          I doubt it has anything to do with the Jenkins core.
          There is no Ruby-related logic in the core itself, and the changes are not obviously related.

          I would suppose there is a sporadic issue in the Ruby Runtime Plugin

          Oleg Nenashev added a comment - I doubt it has anything to do with the Jenkins core. There is no Ruby-related logic in the core itself, and the changes are not obviously related. I would suppose there is a sporadic issue in the Ruby Runtime Plugin
          Oleg Nenashev made changes -
          Component/s New: ruby-runtime-plugin [ 16320 ]

          Daniel Beck added a comment -

          Going by https://github.com/jenkinsci/rvm-plugin/blob/master/models/rvm_wrapper.rb#L33 this seems to be caused by the recent changes to TaskListener that moved behavior into Java 8 default methods.

          I'm surprised it took this long for the ruby-runtime to break.

          Daniel Beck added a comment - Going by https://github.com/jenkinsci/rvm-plugin/blob/master/models/rvm_wrapper.rb#L33 this seems to be caused by the recent changes to TaskListener that moved behavior into Java 8 default methods. I'm surprised it took this long for the ruby-runtime to break.

          Daniel Beck added a comment -

          Perhaps as https://github.com/jenkinsci/jenkins.rb/blob/master/ruby-runtime/lib/jenkins/model/listener.rb seems to assume every object it gets is an AbstractTaskListener, and that's no longer the case?

          Daniel Beck added a comment - Perhaps as https://github.com/jenkinsci/jenkins.rb/blob/master/ruby-runtime/lib/jenkins/model/listener.rb seems to assume every object it gets is an AbstractTaskListener, and that's no longer the case?

          Oleg Nenashev added a comment -

          Seems so. Thanks for digging into danielbeck. I think the valid fix would be to restore binary compatibility in the core. Generally this issue has been captured in https://github.com/jenkinsci/jenkins/pull/3122 by reviews, but after 2 weeks there was no extra votes from code reviewers. So I went forward and merged it. Not the first time we get into "ridiculous" use-cases, so probably the ultra-conservative approach is the only way while we have no API deprecation policy.

          P.S: I will stop merging BC-breaking things at all. If somebody wants to push them into the core, he/she has to find another person to merge iton the API deprecation policy.

          Oleg Nenashev added a comment - Seems so. Thanks for digging into danielbeck . I think the valid fix would be to restore binary compatibility in the core. Generally this issue has been captured in https://github.com/jenkinsci/jenkins/pull/3122 by reviews, but after 2 weeks there was no extra votes from code reviewers. So I went forward and merged it. Not the first time we get into "ridiculous" use-cases, so probably the ultra-conservative approach is the only way while we have no API deprecation policy. P.S: I will stop merging BC-breaking things at all. If somebody wants to push them into the core, he/she has to find another person to merge iton the API deprecation policy.
          Oleg Nenashev made changes -
          Assignee New: Oleg Nenashev [ oleg_nenashev ]
          Oleg Nenashev made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Oleg Nenashev made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]
          Oleg Nenashev made changes -
          Labels New: regression

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

              Created:
              Updated:
              Resolved: