We also experienced this issue. We provide a shared library which has global state. Unfortunately, this state get's not restored and thus restarting is not possible. We try to restart the pipeline directly from blue ocean.

As everything anyway needs to be serializable it should be possible to store and restore the pipeline's state. 

abayer I reproduced this. any idea? thanks

This is expected - anything outside the pipeline block definitely won’t be preserved, and shared libraries that have state won’t be preserved either. We’re not actually saving the execution state of the Pipeline, we’re restarting it from the selected stage with all inputs and stashes preserved.

abayer doesn't this make the feature somehow useless?

What's the reason not storing the complete pipeline status as it is probably done during jenkins restarts?

My use case is that I need my step to work differently on restart, so I need to save a value from the previous attempt.

The restart feature is wonderful and flexible but loses all data, so we have currently a mandatory process for all restarts that need some data from the previous attempt:

write to file -> stash (restart) unstash -> read from file

It seems to be a very common use case, so some way of preserving some data will very much enhance the experience with restarts.

Wow!  That would indeed solve my problem at least: I just need to save a number.  For a few values this would be more than enough.  And for something more elaborate the stash/unstash would be justifiable.

This could perhaps provide another workaround for https://issues.jenkins-ci.org/browse/JENKINS-53193  as checking for the value of a variable can indicate if it is a restart or not.

I feel like it's probably not ideal for that latter scenario, but I'll talk about that over on JENKINS-53913. =)

What about the original issue? Is there a plan to restore more in the future than just the stashes. 
Our use case is, that we are reading some configuration in the init stage and store them in a global variable or singleton object (object defined in vars of a lib). The configuration is basically about which stages in the declarative pipeline should be skipped but it contains also information to define the behavior of stages, e.g. where to deploy. 
Without that configuration it does not make sense to restart at a certain stage, because it will not skip stages as defined in the configuration or deployment information are missing. 
Thus, we need the possibility to restore additional state or have some initialization method in case the pipeline is restarted at a later stage.

kurzy - no, just stashes - preserving program state (like global variables or singletons) is a deeper, more complex problem area than Declarative goes, and is replete with painpoints. Sorry.

kurzy I saved some state in a file and if it fails and is restarted I read what I need from that file (you need set preserveStashes() I believe, I did it but I am not sure). It worked fine. For skipping steps, etc., there is a JIRA to get the isRestartedRun() and isRestartedStage() into variables that can be used outside of the when{}

abayer This issue is affecting us also, if you can suggest a temporary work around that would help us Thanks

Restarting a stage from the original build will work, but restarting a stage twice does not work (restarting a failed restarted stage).

We rely on environment variables instead of global variables

Hello,

We're using a lot of classes in our pipeline libraries, and instead of passing the WorkflowScript in every single function, we are keeping a reference of that WorkflowScript in a Singleton in order to access Pipeline Functions from any of the classes. We are initializing that singleton at the beginning of our pipelines.

I just noticed that we are losing the reference on the WorkflowScript on restarts, so our Pipeline is failing on the next access to the WorkflowScript singleton...

Would it be somehow possible for us to reset that reference? Maybe adding some kind of configurable `onResume` callback where we could reset some of those global/singletons ourselves?

Thanks

As designed. Restart of stages in Declarative Pipeline simply means running a new build with a flag set to skip earlier stages, and with some stuff copied over like parameters and stashes.

The CloudBees CI checkpoint step for Scripted syntax does support something close to what is requested here, though not for static variables (fields) in particular; nor are these restored after resuming a build across controller restarts. Use a lexical variable (def) instead, or object instance fields, etc.

(It would be helpful for the Pipeline engine to issue a warning when you are trying to set a static field that this state might be lost. The logging API introduced for JENKINS-31314 could help here. Maybe the engine could track such saves and add them to the program state, though this seems like it would just be encouraging a bad practice. Anyway, again, this would have no effect on the reported issue about Declarative stage restart, which does not operate at the Groovy level and is only effective for truly declarative Jenkinsfile’s with no script blocks or the like.