p4paul, I think this issue may have been related to your suggestion from https://issues.jenkins-ci.org/browse/JENKINS-35314?focusedCommentId=265033&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-265033.

I reverted the top-level project definition to using the ... wildcard for mapping the workspace to look like this:

//depot/project1/tip... //client_workspace_project1/...

Using the 'Jenkinsfile' style also had the unintended consequence of the changelist info for each build not being populated (my guess was because we were effectively masking off inspecting the rest of the repo for any changes that could trigger a build). Builds were also triggered sometimes with (seemingly) no changes as well as a result. Changed it back to the example above, and things seem to be going quite a bit better now.

That is what I am doing now. Here's the project checkout definition for Jenkinsfile:

Workspace Name: jenkins-project-tip-jenkinsfile
View Mapping: //depot/project/tip/Jenkinsfile //jenkins-project-tip-jenkinsfile/Jenkinsfile

And here's what a checkout DSL looks like from that above Jenkinsfile (there's a couple, all with unique workspace client names). Note that the var $p4DepotPath is "//depot/project/tip" below:

                checkout(
                    [
                        $class: 'PerforceScm',
                        credential: "${p4CredentialsUUID}",
                        populate:
                            [
                                $class: 'ForceCleanImpl',
                                have: false,
                                pin: '',
                                quiet: false,
                                parallel: [ enable: false, minbytes: '1024', minfiles: '1', path: '/usr/bin/p4', threads: '4' ]
                            ],
                        workspace:
                            [
                                $class: 'ManualWorkspaceImpl',
                                charset: 'none',
                                name: "jenkins-${env.NODE_NAME}-${env.JOB_NAME}-build-${env.BUILD_NUMBER}",
                                pinHost: true,
                                spec:
                                    [
                                        allwrite: false,
                                        backup: false,
                                        clobber: false,
                                        compress: false,
                                        line: 'LOCAL',
                                        locked: false,
                                        modtime: false,
                                        rmdir: false,
                                        serverID: '',
                                        streamName: '',
                                        type: 'WRITABLE',
                                        view: "${p4DepotPath}... //jenkins-${env.NODE_NAME}-${env.JOB_NAME}-build-${env.BUILD_NUMBER}/..."
                                    ]
                            ]
                    ]
                )

p4paul, should I be doing something different?

SyncID's are derived from the workspace name and need to be unique across different workspaces (as the change number represents a different view), but unique across build history (so we can find them).  The 'env.BUILD_NUMBER' will break this as each build will create a unique SyncID and we won't be able to find the previous build change.

To avoid this the code looks to replace BUILD_NUMBER, but I noticed recently users are adding 'env.' which will prevent the auto-replace. You could remove the 'env.BUILD_NUMBER' from your workspace or manually set the hidden field 'syncID':

syncID: "jenkins-${env.NODE_NAME}-${env.JOB_NAME}"

https://github.com/jenkinsci/p4-plugin/blob/master/WORKFLOW.md#advanced-polling

p4paul assuming I leave the mapping for the Jenkinsfile as-is:

Workspace Name: jenkins-project-tip-script
View Mapping: //depot/project/tip/Jenkinsfile //jenkins-project-tip-script/Jenkinsfile

The only thing I need to do now is in each of my checkout DSL calls in the Jenkinsfile, adjust my workspace name to the following, without env.BUILD_NUMBER:

name: "jenkins-${env.NODE_NAME}-${env.JOB_NAME}-build",

And that should bring in changelists for that sync step for each build? We have multiple in our Jenkinsfile, one for build (above) and one for test (on a different node)--changelists should be available across both checkout() DSL steps in the build with the above adjustments?

Yes leave the Jenkinsfile workspace and view as-is.

Within your Jenkins file:
1. Try to use different workspace names for different syncs (especially if the view maps different files).

• e.g. steps for sync source, sync assets, sync tests should all use different named workspaces.

2. Ensure that subsequent builds use the same name for the workspace for the corresponding step (or override the syncID).

• e.g. don't use a build ID, UUID or date/time in the workspace name.
   

p4paul I think I got this resolved using your suggestions, thanks. No ghost builds are triggered, and each build has the correct changesets listed (from what I can tell). Feel free to close, if I run into this again, I will re-open.

Hi Kyle, thank you for letting me know the issues is resolves.
I will close it as 'Not A Defect'.

Using jenkins 2.134 and P4 plugin 1.8.14, I have the problem described in the title of this bug. Using the option to pull a jenkinsfile from SCM, I find the $P4_CHANGELIST variable inside the jenkinsfile code is set to the most recent changelist for the pipeline script itself, and not for the overall project (that gets pulled in the P4 Sync stage of the pipeline). The logs show the P4 plugin does successfully pull the latest changelist (for the project) when it pulls the code in P4 Sync, but the P4_CHANGLIST variable is not reset to this changelist, and continues to identify the last change to the pipeline script. Based on the information in this bug (and the latest P4 Plugin documentation), I am using a different job name in the jenkins UI where I ask to pull the pipeline from SCM (jenkins-${NODE_NAME}${JOB_NAME}-script) and in the P4 Sync stage (jenkins${NODE_NAME}-${JOB_NAME}). 

Hello, just wanted to add that I'm seeing similar behavior to the commented before me. I'm using the pipeline from SCM option with a different workspace, and during the build it's setting P4_CHANGELIST to the value in the first pipeline-only sync, and not getting updated when the subsequent sync pulls the code down. I think this is due to that P4_CHANGELIST variable being set only in the 'buildEnvironment' function, which I think only gets called once when setting up the environment. We can't think of a good in-jenkins way to fix this, and will workaround the issue in our own scripts for now.

Hi, I am also seeing similar issue and it's kind of blocker, We needed to do some hacks to keep going for now but it is not efficient.

Here is how our setup is, We have pipeline jobs and  two p4 clients for each job one p4 client is for getting jenkinsfile from p4(using pipeline from SCM option ) and at this point P4_CHANGELIST  is getting set to latest CL of that particular jenkinsfile.

We have 2nd p4 client which we use for getting actual build related code and here even after syncing code from 2nd p4 client, Still P4_CHANGELIST has value of latest CL of that jenkinsfile but not from the latest CL from 2nd p4 client which we use for getting actual build related code.

We needed this P4_CHANGELIST for further stages as part of our build flow and it is also blocking us from enabling percl builds.