Minor The value of P4_CHANGELIST always reflects the requested sync changelist. The actual synced changelist value is less than or equal to the requested sync changelist, depending on the client view. The value of P4_CHANGELIST should always reflect the actual synced changelist value.
[JENKINS-57534] P4_CHANGELIST entry in map returned by checkout step is sometimes wrong
Hi p4karl,
I can repro the issue by triggering a job manually with a specific changelist number provided as a parameter. The workspace map is be being restricted through a virtual stream. The requested changelist contains only files excluded by the virtual stream.
Looking through the code, I believe the issue is in CheckoutTask#getBuildChange(Workspace workspace) which is called by CheckoutTask#initialise().
In my case, the populate label is set to '${Changelist}' which references a String parameter to specify the changelist number to sync. The Expand replaces this token and parses an integer from the String parameter value. This integer is used to create a new P4ChangeRef which is then returned as the build change. I believe this function needs to run a second 'p4 changes -m1 //WORKSPACE/...@${build.getChange()}' to determine the correct build change value for the workspace's view.
If I have time this week, I can put together a PR with a new test case and fix.
Stuart Rowe
added a comment - - edited Hi p4karl ,
I can repro the issue by triggering a job manually with a specific changelist number provided as a parameter. The workspace map is be being restricted through a virtual stream. The requested changelist contains only files excluded by the virtual stream.
Looking through the code, I believe the issue is in CheckoutTask#getBuildChange(Workspace workspace) which is called by CheckoutTask#initialise() .
In my case, the populate label is set to '${Changelist}' which references a String parameter to specify the changelist number to sync. The Expand replaces this token and parses an integer from the String parameter value. This integer is used to create a new P4ChangeRef which is then returned as the build change. I believe this function needs to run a second 'p4 changes -m1 //WORKSPACE/...@${build.getChange()}' to determine the correct build change value for the workspace's view.
If I have time this week, I can put together a PR with a new test case and fix. 
Karl Wirth
added a comment - Hi stuartrowe - Thanks for the confirmation. I'll add some repro steps.
Karl Wirth
added a comment - Hi stuartrowe - Thanks for the confirmation. I'll add some repro steps. Stuart Rowe
added a comment - I've submitted a PR with a test case and fix: https://github.com/jenkinsci/p4-plugin/pull/100
Stuart Rowe
added a comment - I've submitted a PR with a test case and fix: https://github.com/jenkinsci/p4-plugin/pull/100 Karl Wirth
added a comment - Hi stuartrowe, That's create thank you very much. I'll make sure Dev know about it.
Karl Wirth
added a comment - Hi stuartrowe , That's create thank you very much. I'll make sure Dev know about it. 
Paul Allen
added a comment - Release in 1.10.0 
Hi stuartrowe. Thanks for highlighting this. I could understand why this happens. The system does a `p4 changes -m1 //WORKSPACE/...` which retrurns the highest changelist synced to the workspace view.
Can you please let me know how the job is being triggered and how the workspace map is being restricted so I can repro this here.