During a  

checkout perforce(…)  

something outside the jenkins process caused the user session to end – might have been a server failover, or maybe a human or script issuing a p4 logout, or just a bug in the p4 stack somewhere. This looks like it might have happened immediately before the plugin issued the p4 sync to the desired checkout revision.  

The result is that the crucial "P4 Task: syncing files at change: 831729" failed, but the plugin did not catch the error and therefore the step as a whole succeeded, leaving the build with an unexpected (old) revision. It would be better to fail. I think this is difficult to reproduce precisely, but getting the correct revision is clearly critical.  

Here is some annotated detail from the checkout output.  

The early checks for the remaining life of the login session are good:  

Executor number at runtime: 0  

(p4):cmd:... p4 login -s  

p4 login -s  
User p4builduser ticket expires in 11 hours 25 minutes.

There are a bunch of successful calls including for example getting details of changes: 

P4 Task: reverting all pending and shelved revisions. 
(p4):cmd:... p4 revert /home/build/jenkins/workspace/Full/... 
/home/build/jenkins/workspace/Full/... - file(s) not opened on this client. 
P4 Task: cleaning workspace to match have list. 
(p4):cmd:... p4 reconcile -f -w /home/build/jenkins/workspace/Full/... 
P4: saving built changes. 
Found last change 831703 on syncID tw-jenkins-noarch-Full 
(p4):cmd:... p4 login -s 
p4 login -s
 
User p4builduser ticket expires in 11 hours 58 minutes.  

When it gets to the sync command, to sync the changes to the correct revision, it fails to do so due to an access failure, but more importantly, it fails to notice, which means we have a checkout from the previous build, but it has NOT been updated and is therefore wrong. 

(p4):stop:9  

duration: 1m 52s  
P4 Task: syncing files at change: 831729  

(p4):cmd:... p4 sync --parallel=threads=4,min=1,minsize=1024 -q /home/build/jenkins/works___  

Perforce password (P4PASSWD) invalid or unset.  
 
(p4):stop:10  

duration: (458ms) 

 Now we have a checkout which does not match other checkouts involved in a co-ordinated build. But the plugin continues, including successful perforce commands – I am not sure if the plugin logged back in, or whether whatever caused the logout logged back in, or whether the message was misleading, but further calls worked, e.g. this changes command: 

(p4):cmd:... p4 changes -l -m1 @831710  

p4 changes -l -m1 @831710  

Change 831710 on 2021/03/03 by XXXXXXX@XXXXXX 'commit message redacted'  

(p4):stop:37  

After this, the build continues but with the wrong revision checked out, and the checkout step is marked as successful.