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

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

    Details

    • Similar Issues:

      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

            Hide
            batmat Baptiste Mathus added a comment -

            Devin Nusbaum Vivek Pandey Jenn Briden this issue/question has surfaced during the Platform SIG meeting, could it please be triaged and possible options be studied? Thanks!

            Show
            batmat Baptiste Mathus added a comment - Devin Nusbaum Vivek Pandey Jenn Briden this issue/question has surfaced during the Platform SIG meeting, could it please be triaged and possible options be studied? Thanks!
            Hide
            dnusbaum Devin Nusbaum added a comment -

            I discussed this with Sam Van Oort 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.

            Show
            dnusbaum Devin Nusbaum added a comment - I discussed this with Sam Van Oort 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                olivergondza Oliver Gond┼ża
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: