Major I have a build flow that gets triggered by an SCMTRIGGER (ie "Polling per change"). It creates a downstream build job where the expectation is that it would use the SCMTRIGGER changelist to sync on. This is not the case, however, if a checkin has occured after the initial job was triggered. It will pick up all changes and sync to the latest for the downstream build.
When I look at the env vars for the downstream job, I see both a CHANGELIST and a P4_CHANGELIST. The first one is the correct CL, the other is the wrong CL for this job. An easy fix would be to use the CHANGELIST instead of the P4_CHANGELIST to sync on. (Can I override the P4_CHANGELIST as a build parameter being passed in??)
Here is a breakdown of the initial SCMTRIGGER postcheckin job and the subsequent DOWNSTREAM build job it spawned (Perforce changes followed by pertinent env vars for each):
////////////////////////////////////////////////////////////////////////////////////////////
// Build #809 (SCMTRIGGER)
////////////////////////////////////////////////////////////////////////////////////////////
POLLING LOG:
------------
View as plain text
This page captures the polling log that triggered this build.
Started on Jul 7, 2015 6:09:47 PM
Polling SCM changes on master
P4: Polling on: master with:jenkins_XXX_postcheckin
... p4 client -o jenkins_XXX_postcheckin
+
P4 Task: establishing connection.
... server: perforce.XXX.com:3666
... node: XXX001
... p4 cstat //jenkins_XXX_postcheckin/...
+
P4: Polling with label/change: 441291,now
... p4 changes -m100 //jenkins_XXX_postcheckin/...@441291,now
+
... p4 change -o 441300
+
... p4 describe -s 441300
+
... found change: 441300
next change: 441300
Done. Took 1.6 sec
Changes found
ENVIRONMENT VARIABLES:
----------------------
...
BUILD_CAUSE SCMTRIGGER,SCMTRIGGER
BUILD_CAUSE_SCMTRIGGER true
BUILD_DISPLAY_NAME #809
BUILD_ID 809
BUILD_NUMBER 809
...
EXECUTOR_NUMBER -1
...
JOB_NAME postcheckin_XXX
...
NODE_LABELS master
...
ROOT_BUILD_CAUSE SCMTRIGGER
ROOT_BUILD_CAUSE_SCMTRIGGER true
...
////////////////////////////////////////////////////////////////////////////////////////////
// Build #5649 (UPSTREAMTRIGGER)
////////////////////////////////////////////////////////////////////////////////////////////
CHANGES:
--------
441304 by XXX on Jul 7, 2015 6:23:17 AM
...
441300 by XXX on Jul 7, 2015 6:08:44 AM
ENVIRONMENT VARIABLES:
----------------------
...
BUILD_CAUSE UPSTREAMTRIGGER
BUILD_CAUSE_UPSTREAMTRIGGER true
BUILD_DISPLAY_NAME #5649
BUILD_ID 5649
BUILD_NUMBER 5649
...
CHANGELIST 441300 <=============== This is the CORRECT upstream CL
...
EXECUTOR_NUMBER 0
...
JOB_NAME build_XXX
...
NODE_LABELS build_pool
...
P4_CHANGELIST 441304 <=============== This is the INCORRECT latest CL
P4_CLIENT jenkins_XXX_build
...
ROOT_BUILD_CAUSE SCMTRIGGER
ROOT_BUILD_CAUSE_SCMTRIGGER true
...
[JENKINS-29296] P4 Plugin: Downstream job not using correct changelist
Setting 'change' as a parameter worked like a charm. This suits my needs for now. Thanks.
I think the CHANGELIST var is commonly used - not just in the Build Flow plugin, but the old Perforce plugin as well - though you should verify if it is a standard Jenkins SCM environment var. My assumption was that your plugin was using it as well. I'm fine with using the "change" var going forward.
Not sure who sets the P4_CHANGELIST var, though, as I assumed it was your plugin. I'm not using it so I really don't care one way or the other there.
I have not contacted the support team regarding this btw.
EDIT: I'm actually not sure who sets P4_CHANGELIST vs CHANGELIST for various types of jobs. Verify that if you intend to use either, but "change" works fine for me now as a parameter I pass in.
Martin Hulth
added a comment - - edited Setting 'change' as a parameter worked like a charm. This suits my needs for now. Thanks.
I think the CHANGELIST var is commonly used - not just in the Build Flow plugin, but the old Perforce plugin as well - though you should verify if it is a standard Jenkins SCM environment var. My assumption was that your plugin was using it as well. I'm fine with using the "change" var going forward.
Not sure who sets the P4_CHANGELIST var, though, as I assumed it was your plugin. I'm not using it so I really don't care one way or the other there.
I have not contacted the support team regarding this btw.
EDIT: I'm actually not sure who sets P4_CHANGELIST vs CHANGELIST for various types of jobs. Verify that if you intend to use either, but "change" works fine for me now as a parameter I pass in. 
Paul Allen
added a comment - Glad to hear this has resolved your issue. The 'change' param is used by the 'Perforce Swarm' review integration and is read at the start of the build. I added P4_CHANGELIST early on in development, to help downstream Jobs and labels, but it is not read at the start of a build.
I don't know where CHANGELIST is set perhaps another plugin?
Paul Allen
added a comment - Glad to hear this has resolved your issue. The 'change' param is used by the 'Perforce Swarm' review integration and is read at the start of the build. I added P4_CHANGELIST early on in development, to help downstream Jobs and labels, but it is not read at the start of a build.
I don't know where CHANGELIST is set perhaps another plugin? Paul Allen
added a comment - Use the 'change' param to set the change and P4_CHANGELIST to evaluate the change used in the build.
Note: their values may not be the same.
For example, take a code line //depot/projA/src/... with changes:
change 196 'Fix A'
change 198 'Fix B'
change 204 'Feature X'
Setting 'change' to 200 will build from that change, but the last submitted change under the code line might be 198, so P4_CHANGELIST will report 198.
Paul Allen
added a comment - Use the 'change' param to set the change and P4_CHANGELIST to evaluate the change used in the build.
Note: their values may not be the same.
For example, take a code line //depot/projA/src/... with changes:
change 196 'Fix A'
change 198 'Fix B'
change 204 'Feature X'
Setting 'change' to 200 will build from that change, but the last submitted change under the code line might be 198, so P4_CHANGELIST will report 198. Martin Hulth
added a comment - Thanks for the follow-up and clarification. The plugin is working great now.
Martin Hulth
added a comment - Thanks for the follow-up and clarification. The plugin is working great now. Paul Allen
added a comment - Resolved to Closed 
You can use 'change' (as a build parameter) to override the changelist that 'p4' will use for the sync.
Did you raise this with our support team? It's just I have had a very similar question from support.
I'm not familiar with mechanics of the Build Flow plugin, I'll need to setup a test environment to see if I can reproduce this. Do let me know if setting 'change' works as an alternative.