Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-55396

Consider options for graceful termination of interrupted pipelines during jboss marshalling upgrade

XMLWordPrintable

      As discussed on Pipeline SIG meeting in Java 11 hackathon in Nice, the pipelines resumed just after plugin upgrade that brings in new version of jboss marshalling will be aborted.

      However, it would be good to clearly indicate those pipelines failed for this very reason instead of presenting big and scary exception to the end users. I know there will be warnings everywhere but people tend to overlook things like that. Putting aside warnings will be presented to instance admins while the failed builds to instance users.

          [JENKINS-55396] Consider options for graceful termination of interrupted pipelines during jboss marshalling upgrade

          Baptiste Mathus added a comment -

          dnusbaum vivek jbriden this issue/question has surfaced during the Platform SIG meeting, could it please be triaged and possible options be studied? Thanks!

          Baptiste Mathus added a comment - dnusbaum vivek jbriden this issue/question has surfaced during the Platform SIG meeting, could it please be triaged and possible options be studied? Thanks!

          Devin Nusbaum added a comment -

          I discussed this with svanoort before we released workflow-support 3.0. In short, it is not trivial to determine if a Pipeline failed to deserialize because we just upgraded to workflow-support 3.x or if the Pipeline was legitimately broken (e.g., file was corrupted). Jenkins core tracks version information to understand when core is updated, but I am not aware of any such information for plugins (maybe could be approximated by adding some kind of persistent field to the plugin somewhere that is null on upgrade and gets set explicitly on shutdown?). We could try to handle the very specific NullPointerException in SerializableScript specially by inspecting the stack trace, but that seems like a messy approach, especially considering that once people make it to 3.0 once any such compatibility code would be useless.

          Devin Nusbaum added a comment - I discussed this with svanoort before we released workflow-support 3.0. In short, it is not trivial to determine if a Pipeline failed to deserialize because we just upgraded to workflow-support 3.x or if the Pipeline was legitimately broken (e.g., file was corrupted). Jenkins core tracks version information to understand when core is updated, but I am not aware of any such information for plugins (maybe could be approximated by adding some kind of persistent field to the plugin somewhere that is null on upgrade and gets set explicitly on shutdown?). We could try to handle the very specific NullPointerException in SerializableScript specially by inspecting the stack trace, but that seems like a messy approach, especially considering that once people make it to 3.0 once any such compatibility code would be useless.

          Jesse Glick added a comment -

          At this point I suppose this issue can be closed as will not fix?

          Jesse Glick added a comment - At this point I suppose this issue can be closed as will not fix?

          Basil Crow added a comment -

          At this point, fully 92% of workflow-support users have already upgraded past 3.x. Closing as "Won't Fix".

          Basil Crow added a comment - At this point, fully 92% of workflow-support users have already upgraded past 3.x. Closing as "Won't Fix".

            Unassigned Unassigned
            olivergondza Oliver Gondža
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: