I am noticing an odd issue where our P4_CHANGELIST number is populated per the last set of changes to the Jenkinfs file, but not for any 'p4sync' calls in the Jenkinsfile itself.
As an example, here's the initial Jenkinsfile sync snippet, notice the changelist "961423". From here on out, the P4_CHANGELIST variable will have that as it's changelist number.
[... snip ...] P4 Task: reverting all pending and shelved revisions. ... p4 revert /home/jenkins/jobs/build-tip/workspace%40script/... + ... rm [abandoned files] duration: (106ms) ... p4 sync /home/jenkins/jobs/build-tip/workspace%40script/...#none + ... rm -rf /home/jenkins/jobs/build-tip/workspace%40script P4 Task: syncing files at change: 961423 ... p4 sync -p /home/jenkins/jobs/build-tip/workspace%40script/...@961423 + duration: (158ms) P4 Task: saving built changes. Found last change 961423 on syncID jenkins-build-tip ... p4 client -o jenkins-build-tip + ... p4 info + ... p4 client -o jenkins-build-tip + ... p4 info + ... done [... snip ...]
A little farther in my build, I have my actual repo mappings. Here's the sync log from it:
[... snip ...] P4 Task: reverting all pending and shelved revisions. ... p4 revert /home/jenkins/workspace/build-tip/... + ... rm [abandoned files] duration: (160ms) ... p4 sync /home/jenkins/workspace/build-tip/...#none + ... rm -rf /home/jenkins/workspace/build-tip P4 Task: syncing files at change: 968942 ... p4 sync -p /home/jenkins/workspace/build-tip/...@968942 + duration: 9m 8s P4 Task: saving built changes. Found last change 968924 on syncID jenkins-build-01 ... p4 client -o jenkins-build-01 + ... p4 info + ... p4 changes //jenkins-build-01/...@968924,968942 + ... p4 changes -l -m1 @968942 + ... p4 user -o user1 + ... p4 describe -s 968942 + ... p4 fixes -c968942 + ... p4 changes -l -m1 @968936 + ... p4 user -o user2 + ... p4 describe -s 968936 + ... p4 fixes -c968936 + ... done [... snip ...]
In the case above, I would expect P4_CHANGELIST to be 968942, as it is the newest changelist for the repo at that point in the Jenkinsfile. If I were to have a workflow step right after my p4sync call that did something like this:
sh "echo ${env.P4_CHANGELIST}"
I would want the output to be '968942', but right now, it outputs '961423'.
There are two syncs occurring: one to fetch the Jenkinsfile and the other to fetch your source as described in the Jenkinsfile by 'p4sync' or 'checkout' DSL. You MUST use different workspace names as the workspace names form part of the syncID used to record what was synced in a build.
I normally postfix my Jenkinsfile workspace with '-script' and limit the view to just include the Jenkinsfile. The sync stage in the script I leave the Workspace name to the default format value. Now I get two unique 'syncID's in the build XML data and can differentiate the changelists when computing polling or change reporting.
Environment variables have always been problematic in Jenkins and depend heavily on scope, once set Jenkins seems to be reluctant to update them. Please double check your workspace naming convention and if it is still a problem I'll take a closer look.