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

Restarting stages

    XMLWordPrintable

    Details

    • Similar Issues:
    • Sprint:
      Pipeline - April 2018

      Description

      Use cases

      • Restarting a successful stage so to rollback or redeploy code
      • When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

      In scope

      • Declarative pipeline only
      • Restart the stage with the same parameters/scm/actions as the previous run
      • No management of workspace
      • Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
        • Implication is we do not have to copy flow nodes to the new run
      • Add a when condition that will evaluate as true only when on a restarted 

      Out of scope

      • Automatically stash/unstash the workspace
      • Scripted pipeline (technical limitation)

      Open questions

      • Should we be keeping stash data for every run? What is the option of least surprise?
        • JD thinks that keeping stashes around by default is the least surprising option - that way they do not have to turn anything on to make the feature work.
        • AB says this might blow out the storage requirements

      Notes
      There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

      Technical notes
      Split off from JENKINS-33846 since Andrew Bayer removed the component from that one, and I do not want this lost:

      For Declarative Pipelines, in principle you could skip some early stage's and just start running on a later one, using FlowCopier.

      This would be instead of using a checkpoint step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it could be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

      (Conversely, you could also offer the ability to run a build skipping some of the later stages, somewhat analogously to running ant some-non-default-target.)

        Attachments

          Issue Links

            Activity

            jglick Jesse Glick created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Link This issue relates to JENKINS-33846 [ JENKINS-33846 ]
            jglick Jesse Glick made changes -
            Description Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Description Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use case*
            When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Original description*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Description *Use case*
            When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Original description*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use case*
            When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Link This issue is duplicated by JENKINS-46043 [ JENKINS-46043 ]
            jamesdumay James Dumay made changes -
            Summary Restart Declarative stage after failure Restart declarative stage
            jamesdumay James Dumay made changes -
            Description *Use case*
            When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Epic Link JENKINS-48356 [ 186951 ]
            jamesdumay James Dumay made changes -
            Sprint Pipeline - Candidates [ 381 ]
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal CD-367 (Web Link)" [ 18941 ]
            jamesdumay James Dumay made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History
            ** Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.

            *Out of scope*
            * Automatically stash/unstash the workspace

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History
            ** Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.

            *Out of scope*
            * Automatically stash/unstash the workspace

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History
            ** Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Alternatively: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History
            ** Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Alternatively: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History - investigate and touch base with James on findings:
            ** Option 1: Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Option 2: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Sprint Pipeline - Candidates [ 381 ] Pipeline - December [ 446 ]
            jamesdumay James Dumay made changes -
            Summary Restart declarative stage Restarting stages
            jamesdumay James Dumay made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History - investigate and touch base with James on findings:
            ** Option 1: Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Option 2: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History - investigate and touch base with James on findings:
            ** Option 1: Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Option 2: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History - investigate and touch base with James on findings:
            ** Option 1: Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Option 2: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History - investigate and touch base with James on findings:
            ** Option 1: Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Option 2: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            abayer Andrew Bayer made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            abayer Andrew Bayer made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            jamesdumay James Dumay made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * History - investigate and touch base with James on findings:
            ** Option 1: Need to investigate if we can reuse the Pipeline Run. For example, if we have a Pipeline "Build -> Test -> Deploy" and we restarted the "Test" stage, the same run is reused and Deploy stage would be set to "not built". This would lose the history of proceeding stages.
            ** Option 2: can we graft the information from the previous run to the new run?

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
            ** Implication is we do not have to copy flow nodes to the new run

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            jamesdumay James Dumay made changes -
            Link This issue blocks JENKINS-48643 [ JENKINS-48643 ]
            jamesdumay James Dumay made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
            ** Implication is we do not have to copy flow nodes to the new run

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
            ** Implication is we do not have to copy flow nodes to the new run

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Open questions*
            * Should we be keeping stash data for every run? What is the option of least surprise?
            ** JD thinks that keeping stashes around by default is the least surprising option - that way they do not have to turn anything on to make the feature work.
            ** AB says this might blow out the storage requirements

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            abayer Andrew Bayer made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
            ** Implication is we do not have to copy flow nodes to the new run

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Open questions*
            * Should we be keeping stash data for every run? What is the option of least surprise?
            ** JD thinks that keeping stashes around by default is the least surprising option - that way they do not have to turn anything on to make the feature work.
            ** AB says this might blow out the storage requirements

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
            ** Implication is we do not have to copy flow nodes to the new run
            * Add a {{when}} condition that will evaluate as true only when on a restarted run.

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Open questions*
            * Should we be keeping stash data for every run? What is the option of least surprise?
            ** JD thinks that keeping stashes around by default is the least surprising option - that way they do not have to turn anything on to make the feature work.
            ** AB says this might blow out the storage requirements

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "PR #228 (Web Link)" [ 20121 ]
            vivek Vivek Pandey made changes -
            Sprint Pipeline - December [ 446 ] Pipeline - March 2018 [ 506 ]
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal UX-733 (Web Link)" [ 20813 ]
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal UX-729 (Web Link)" [ 20814 ]
            ranjith_kumar ranjith kumar made changes -
            Description *Use cases*
            * Restarting a successful stage so to rollback or redeploy code
            * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
            * Declarative pipeline only
            * Restart the stage with the same parameters/scm/actions as the previous run
            * No management of workspace
            * Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
            ** Implication is we do not have to copy flow nodes to the new run
            * Add a {{when}} condition that will evaluate as true only when on a restarted run.

            *Out of scope*
            * Automatically stash/unstash the workspace
            * Scripted pipeline (technical limitation)

            *Open questions*
            * Should we be keeping stash data for every run? What is the option of least surprise?
            ** JD thinks that keeping stashes around by default is the least surprising option - that way they do not have to turn anything on to make the feature work.
            ** AB says this might blow out the storage requirements

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            *Use cases*
             * Restarting a successful stage so to rollback or redeploy code
             * When long running Pipelines fail intermittently for environmental purposes the developer must be able to restart the execution of the stage that failed within the Pipeline. This allows the developer to recoup time lost running the pipeline to the point of failure.

            *In scope*
             * Declarative pipeline only
             * Restart the stage with the same parameters/scm/actions as the previous run
             * No management of workspace
             * Need to be able to union the previous run and the current runs flownodes to produce a visualisation for Blue Ocean
             ** Implication is we do not have to copy flow nodes to the new run
             * Add a {{when}} condition that will evaluate as true only when on a restarted 

            *Out of scope*
             * Automatically stash/unstash the workspace
             * Scripted pipeline (technical limitation)

            *Open questions*
             * Should we be keeping stash data for every run? What is the option of least surprise?
             ** JD thinks that keeping stashes around by default is the least surprising option - that way they do not have to turn anything on to make the feature work.
             ** AB says this might blow out the storage requirements

            *Notes*
            There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only.

            *Technical notes*
            Split off from JENKINS-33846 since [~abayer] removed the component from that one, and I do not want this lost:
            {quote}For Declarative Pipelines, in principle you could skip some early {{stage}}'s and just start running on a later one, using {{FlowCopier}}.
            {quote}
            This would be instead of using a {{checkpoint}} step, and would not be dependent on Groovy internals. While it is less flexible in some respects, it is no less flexible than it _could_ be given the restrictions Declarative already imposes. This behavior would more closely match what you get from, say, the Build Pipeline plugin, but with the benefits of Jenkins Pipeline: stashes, exact SCM revisions, etc.

            (Conversely, you could also offer the ability to run a build skipping some of the _later_ stages, somewhat analogously to running {{ant some-non-default-target}}.)
            abayer Andrew Bayer made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            franknarf8_ni Frank Genois made changes -
            Link This issue is related to JENKINS-52391 [ JENKINS-52391 ]
            victorbjelkholm Victor Bjelkholm made changes -
            Link This issue is related to JENKINS-53730 [ JENKINS-53730 ]
            hoppej Jan Hoppe made changes -
            Link This issue is related to JENKINS-54250 [ JENKINS-54250 ]
            gc Garbageyard made changes -
            Comment [ Thanks for the response [~bdevcich]. Hardware dependency can definitely be one reason but will tying a job to a slave also _ensure_ that subsequent builds will use the same workspace which was used by last failed build? ]
            bitwiseman Liam Newman made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

              People

              Assignee:
              abayer Andrew Bayer
              Reporter:
              jglick Jesse Glick
              Votes:
              63 Vote for this issue
              Watchers:
              110 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: