Using checkpoint inside of node {} is unsupported and unreliable

[niristotle okram]

Due to some requirements of confining the files in the workspace on an instance of a job, i am restricting instances of job to a particular node & specific workspace. The reason for clamping down the node is to avoid overwriting when the concurrent builds are executed. The workflow script looks like below: 

node(XXX) {

ws("C:\\abc\\workspace\\${env.BUILD_NUMBER}") {

// codes of all the stages // 

 }

}

I get the warnings: Using checkpoint inside of node {} is unsupported and unreliable

Do i stop using the checkpoint with my current workflow script design?

[niristotle okram]

Again answering to self: 

If i modify my script to be like the below, i can still confine my files to a workspace and use the checkpoint

stage name 'one', concurrency: 1

node(XXX) {

ws("C:\\abc\\workspace\\${env.BUILD_NUMBER}") {

// codes  // 

 }

}

checkpoint 'post1'

stage name 'two', concurrency: 2

node(XXX) {

ws("C:\\abc\\workspace\\${env.BUILD_NUMBER}") {

// codes  // 

 }

}

[niristotle okram]

There is a possible bug here with the checkpoint implementation and when using the custom workflow. 

Lets say, i am executing the job such that each instance create a unique workspace (in my case, the build_number). Now, i want to resume (using a checkpoint) a previous job, the new job starts from the old workspace of the previous job, which is right. But when it enters the next stage, it create a new workspace and if there is a dependency on the data from the previous workspace. The job fails as the new workspace doesn't have any files in it from the previous stages.

IMHO, the job should continue withing the old workspace and not create a new one. Is there any reason why it should create a new workspace, to me we are reexecuting or continuing the old stopped or failed or successful job.