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

Ready for release.

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