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:

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.)