A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. To visualize the issue in stage 'two' the commands 'git show' and 'cat Jenkinsfile will be called'.

To reproduce this issue the following steps are necessary:

1) run job
2) modify Jenkinsfile and commit/push it into git
3) rerun job from stage 'two' 

Running the job the first time, the log contains:

Obtained Jenkinsfile from 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
...
[Pipeline] stage[Pipeline] { (one)[Pipeline] script[Pipeline] {[Pipeline] echojenkins-simpletest2-3[Pipeline] }[Pipeline] // script[Pipeline] }[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (two)
[Pipeline] script
[Pipeline] {
[Pipeline] sh
[workspace] Running shell script
+ git show
commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

Running it the second time:

Obtained Jenkinsfile from d6182967fab6e27b5a43f517e62be5b4d5410099
...  
[Pipeline] stage[Pipeline] { (one)Stage "one" skipped due to this build restarting at stage "two"[Pipeline] }[Pipeline] // stage[Pipeline]  stage[Pipeline] { (two)[Pipeline] script[Pipeline] {[Pipeline] sh[workspace] Running shell script
+ git show
commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

Conclusion

The commit d6182 introduces a println in stage2. This print is missing in the second run and is not displayed by the output of 'cat Jenkinsfile'.

It is clear, that the Jenkinsfile from 2d9e9 was used for the second run. However the log reports, that the Jenkinsfile was obtained from d6182.

I would expect, that the Jenkinsfile from current HEAD (which is d6182 in my case) will be used for jobs 'restarted from stage' as printed in the logs. But the more critical thing is, that another Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.