Any updates on this? Is this still not working as intended?

Working with Daniel on this.

Verified that polling per change does not work with Pipleline jobs if it is configured through the GUI using Polling Build Filters, or when using 'checkout' step.

Variations tested that all fail:

1. Lightweight checkout not selected, polling build filter from GUI
2. Lightweight checkout selected, polling build filter from GUI, 'options { skipDefaultCheckout() }' not set.
3. Lightweight checkout selected, polling build filter from GUI, 'options { skipDefaultCheckout() }' **set.
4. Lightweight checkout not selected, polling build filter from Jenkinsfile checkout step.
5. Lightweight checkout selected, polling build filter from Jenkinsfile checkout step, 'options { skipDefaultCheckout() }' not set.
6. Lightweight checkout selected, polling build filter from Jenkinsfile checkout step, 'options { skipDefaultCheckout() }' set.

Example Jenkinsfile with everything set below:

pipeline {
  agent any
  //options { skipDefaultCheckout() }  
  stages {
    stage("PollPerChange") {
      steps {
        script {
          checkout perforce(credential: 'MasterServer', filter: [incremental(true)], populate: autoClean(delete: true, modtime: false, parallel: [enable: false, minbytes: '1024', minfiles: '1', threads: '4'], pin: '', quiet: true, replace: true, tidy: false), workspace: manualSpec(charset: 'none', name: 'jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER}', pinHost: false, spec: clientSpec(allwrite: false, backup: false, clobber: true, compress: false, line: 'LOCAL', locked: false, modtime: false, rmdir: false, serverID: '', streamName: '', type: 'WRITABLE', view: '//depot/pollperchange/... //jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER}/...')))
            echo "In script."
            sh 'ls'  
        }
      }
    }
  }
}

Commenting on this bug to keep it close to top of backlog list.

p4karl Ping! Any updates?

Hi danielresolutiongames. It's in the backlog but doesn't have a priority yet. Because we have both commented on it, it should be looked at in the next sprint review. I don't know when that will be.

After speaking with Karl, I would like a fix to this bug as well, ping!

Hi Both. For the record can you both add your usage cases for this bug. My understanding is that the desired result you want is:

• trigger a build on every changelist
• only build from last up to changelist that triggered the job

Is this what you expect?

p4karl that is exactly the result I expect

Yeah. I'm looking for incremental builds, to pin down which changelists introduce what behaviour and/or potential problems. I've got more projects than I'd like to set up and maintain p4 submit triggers for, and builds take quite long so I'd prefer if polling e.g. each minute produced this result. In my head, that makes sense, but I could be wrong

Thanks both. Just wanted to make sure I was on the correct track.

Code changed in jenkins
User: Paul Allen
Path:
src/main/java/org/jenkinsci/plugins/p4/PerforceScm.java
src/main/java/org/jenkinsci/plugins/p4/tasks/PollTask.java
src/test/java/org/jenkinsci/plugins/p4/DefaultEnvironment.java
src/test/java/org/jenkinsci/plugins/p4/client/GraphTest.java
src/test/java/org/jenkinsci/plugins/p4/client/PollingTest.java
http://jenkins-ci.org/commit/p4-plugin/931f05a111a66c2002deb8dc80f321bcb3abee72
Log:
Poll per change for Pipeline.

JENKINS-47427

Bad news, I'm afraid. As far as I can tell, the update introduced some problematic behaviour. I'll try to explain with a example.
 
In a project that polls once per minute and a build taking ~2-3 minutes, submits happen with the following timings:
 
Changelist @1 is submitted, which triggers a build, #1, within a minute. All good.
 
During building of #1 with changelist @1, changelists @2 and @3 are submitted.
The multibranch polling log has this:

Changes detected: master (1 → 3)
Scheduled build for branch: master

 
When #1 is done, build #2 starts. Only changelist @2 is included in the build, as it should with incremental builds.
The console output of the actual build job has this:

00:00:00.849 ... p4 change -o 3
 +
00:00:00.860 ... p4 describe -s 3
 +
00:00:00.872 ... found change: 3
00:00:00.872 ... p4 change -o 2
 +
00:00:00.882 ... p4 describe -s 2
 +
00:00:00.893 ... found change: 2

 
However, after automatically triggering #2 with @2, the multibranch polling log has this:

 ... p4 files -e //redacted/master/Jenkinsfile_Android +
      ‘Jenkinsfile_Android’ found
... p4 changes -m1 //redacted/master/... +
No changes detected: master (still at 3)

And no further builds are automatically triggered. That's a problem.
 
If at this point I manually trigger another build, #3, it has @3 only, so the incremental build-functionality "works". 
However, we keep lagging behind, with the rate of one submit per submit more than the first 1 during building.
The polling log seems to note the highest number it has seen when polling, not the highest the job has built.
 
So, in reality, if we have more changelists than we can build over a given time, we're still not getting incremental builds. We're getting incremental builds that as time goes on lags more and more behind, unless somebody manually triggers builds, one for each submit not included in the polling. That's not very useful.
 
Thoughts? ping p4karl

Released in 1.8.10

Original fix was released but reports that fix does not build correctly. We are investigating.

Limited behavior is documented in new job.

Poll per change is tricky when you have one or more p4 sync commands involved. An extreme example is if you have two p4sync commands that sync from different P4D servers in the same Jenkinsfile. In this case advanced logic is needed for the polling to decide which one triggers polling and Jenkins may not even support this scenario.

For now Poll per change only fully works (trigger a job per each submitted changelist and sync up to that changelist only) in the limited scenario documented in JENKINS-51525.

This defect is being closed in favor of JENKINS-51525.

The basic poll per change logic exists and works with pipeline.

Additional investigation and work is needed to get it to work in the more difficult to predetermine scenarios where you rely on the Jenkinsfile contents to inform the polling mechanism on what paths need to be polled and need to cope with situations when the paths in the Jenkinsfile have changed.

Just updating this bug with further information on current behavior for reference only.

With multibranch poll per change doesnt poll every change but does build only the next change that needs to be built.For example:

(1) Add CL 626, 627 and 628.

(2) The multi branch top level poll is configured for 1 min (see below). When it triggers it detects that 625 to 628 exist.

(3) The job checks SyncID and correctly finds '625' as the previous last sync.          __

Found last change 625 on syncID jenkins-NODE_NAME-MultiBranch_PollPerChange-main-EXECUTOR_NUMBER

(4) Due to filtering only the next changelist is synced:

          P4 Task: syncing files at change: 626

(5) Jenkins records the last sucseful buils for this branch correctly:

          branches/main/lastSuccessful/build.xml:          <change>626</change>

(6) But (and I'm guessing this is the cause) sets '628' in the following file:

          branches/main/scm-revision-hash.xml

 The next time a poll runs it will only fire if a new changelist has been created but will build changelist '627' only (so will now be building 2 changelists behind current).

My Jenkinsfile:

     1	pipeline {
     2	  agent { label 'master' }
     3	  options { skipDefaultCheckout() }
     4	  stages {
     5	    stage("Repro") {
     6	      steps {
     7	        script {
     8	           checkout perforce(credential: 'MasterServer', filter: [incremental(true)], populate: autoClean(delete: true, modtime: false, parallel: [enable: false, minbytes: '1024', minfiles: '1', threads: '4'], pin: '', quiet: true, replace: true, tidy: false), workspace: manualSpec(charset: 'none', name: 'jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER}', pinHost: false, spec: clientSpec(allwrite: false, backup: false, clobber: true, compress: false, line: 'LOCAL', locked: false, modtime: false, rmdir: false, serverID: '', streamName: '', type: 'WRITABLE', view: '//depot/multibranch_poll_per_change/main/... //jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER}/...')))
     9	           sh "pwd"
    10	           sh "ls -l"
    11		   sh "cat -n *"
    12		   sh "echo ${env.BRANCH_NAME}"
    13	        }
    14	      }
    15	    }
    16	  }
    17	}

Based on last findings have created a seperate feature request to implement poll per change for multibranch pipeline.

JENKINS-52066