Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-65246

P4 Polling does not work correctly if changelist is specified during sync

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • p4-plugin
    • Jenkins 2.263.3
      P4-Plugin 1.11.2

      If a changelist is specified in scm: checkout, p4 polling does not work.  The result is the specified changelist is used in the range:  

       

      P4: Polling with range: 53910841,53910841 

      p4 changes -m20 //clientname_/...@53910841,53910841

       

      This result, is polling will not detect any subsequent changes.  

       

      If changelist is not specified during scm: checkout, 

       

      P4: Polling with range: 53910841,now 

      p4 changes -m20 //clientname_/...@53910841,now

       

      P4 plugin should always use "now" for the higher end of the range, regardless if a changelist was specified or not.  

       

       

       

          [JENKINS-65246] P4 Polling does not work correctly if changelist is specified during sync

          Al Watson created issue -
          Al Watson made changes -
          Assignee New: Paul Allen [ p4paul ]
          Karl Wirth made changes -
          Assignee Original: Paul Allen [ p4paul ] New: Karl Wirth [ p4karl ]

          Karl Wirth added a comment -

          Hi atwatsoniii

          Please can you show my how you are specifying the changelist in the sync. Is this using pipeline/multibranch pipeline.

          Thanks in advance.

          Karl Wirth added a comment - Hi atwatsoniii Please can you show my how you are specifying the changelist in the sync. Is this using pipeline/multibranch pipeline. Thanks in advance.
          Karl Wirth made changes -
          Labels New: P4_SUPPORT

          Al Watson added a comment -

          Using declarative pipeline:

           

          checkout perforce(

          populate:

          syncOnly(
          force: false,
          have: true,
          modtime: false,
          parallel: [enable: true, minbytes: '1024', minfiles: '1', threads: '4'],
          pin: "${env.CHANGELIST}",
          quiet: true,
          revert: true)

           

           

          Al Watson added a comment - Using declarative pipeline:   checkout perforce( populate: syncOnly( force: false, have: true, modtime: false, parallel: [enable: true, minbytes: '1024', minfiles: '1', threads: '4'] , pin: "${env.CHANGELIST}", quiet: true, revert: true)    

          Karl Wirth added a comment -

          Hi atwatsoniii,

          Thanks. Why are you trying to pin a polled job? Are you trying to implement 'pin at polled' - JENKINS-63879?

          Usually you want polling to find the highest changeslist and then sync to that highest changelist which is the way the code expects. The main reason you dont want to is when the job takes a long time to run on a busy system and contains multiple sync steps that need to be consistent which is what the above enhancement is trying to implement.

          Does your job have one or more than one sync/checkout step? If more than one sync step do you need polling for all the code paths including the pinned one?

          Regards,

          Karl

           

          Karl Wirth added a comment - Hi atwatsoniii , Thanks. Why are you trying to pin a polled job? Are you trying to implement 'pin at polled' - JENKINS-63879 ? Usually you want polling to find the highest changeslist and then sync to that highest changelist which is the way the code expects. The main reason you dont want to is when the job takes a long time to run on a busy system and contains multiple sync steps that need to be consistent which is what the above enhancement is trying to implement. Does your job have one or more than one sync/checkout step? If more than one sync step do you need polling for all the code paths including the pinned one? Regards, Karl  

          Al Watson added a comment -

          I only have one sync step that I want to do polling on, and that's the example above.   However, as an example, I may initiate a manual run at a specific changelist.  In the current paradigm, doing that will disable polling until a run is made without "pin".   What is the reason behind the current methodology?  It seems this behavior is always undesirable, it effectively disables polling.  

          Al Watson added a comment - I only have one sync step that I want to do polling on, and that's the example above.   However, as an example, I may initiate a manual run at a specific changelist.  In the current paradigm, doing that will disable polling until a run is made without "pin".   What is the reason behind the current methodology?  It seems this behavior is always undesirable, it effectively disables polling.  
          Al Watson made changes -
          Comment [ It seems this is potentially a dup of [JENKINS-63879] Using pin to sync to changelist causes polling to no longer detect changes beyond pinned CL - Jenkins Jira ]

          Al Watson added a comment -

          Any updates or questions?

          Al Watson added a comment - Any updates or questions?

            p4karl Karl Wirth
            atwatsoniii Al Watson
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: