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

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

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

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

            batmat 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!
            dnusbaum 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.

            dnusbaum 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.
            jglick Jesse Glick added a comment -

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

            jglick Jesse Glick added a comment - At this point I suppose this issue can be closed as will not fix?
            basil 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 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".

            People

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

              Dates

                Created:
                Updated:
                Resolved: