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

Using pin to sync to changelist causes polling to no longer detect changes beyond pinned CL

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Karls Summary:

      Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

      Usage case - On a busy system a long running job will pickup components of different ages.

      Example -

      • Poll finds latest change 123
      • Build is queued
      • Change 124 added to path1.
      • Build starts
      • Path1 synced at 124
      • Change 125 and 126 submitted to path2.
      • Path1 sync completes, path2 sync starts at 126

      The desired behavior is path1 and path2 should be synced at 123 (if that is not possible in the Jenkins infrastructure path 1 and path2 should be synced at 124).

       

      Original Description:

      HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

       

      Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

      However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

      Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

      Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

       

      I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.

        Attachments

          Activity

          newtopian Eric Daigneault created issue -
          p4karl Karl Wirth made changes -
          Field Original Value New Value
          Assignee Karl Wirth [ p4karl ]
          p4karl Karl Wirth made changes -
          Labels P4_SUPPORT
          p4karl Karl Wirth made changes -
          Description HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          *Karls Summary:*

          Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

          _Usage case_ - On a busy system a long running job will pickup components of different ages.

          _Example_ -
           * Poll finds latest change 123
           * Build is queued
           * Change 124 added to path1.
           * Build starts
           * Path1 synced at 124
           * Change 125 and 126 submitted to path2.
           * Path1 sync completes, path2 sync starts at 126

          The desired behavior is Path2 should be synced at 124.

           

          *Original Description:*

          HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          p4karl Karl Wirth made changes -
          Labels P4_SUPPORT P4_A P4_VERIFY
          p4karl Karl Wirth made changes -
          Description *Karls Summary:*

          Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

          _Usage case_ - On a busy system a long running job will pickup components of different ages.

          _Example_ -
           * Poll finds latest change 123
           * Build is queued
           * Change 124 added to path1.
           * Build starts
           * Path1 synced at 124
           * Change 125 and 126 submitted to path2.
           * Path1 sync completes, path2 sync starts at 126

          The desired behavior is Path2 should be synced at 124.

           

          *Original Description:*

          HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          *Karls Summary:*

          Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

          _Usage case_ - On a busy system a long running job will pickup components of different ages.

          _Example_ -
           * Poll finds latest change 123
           * Build is queued
           * Change 124 added to path1.
           * Build starts
           * Path1 synced at 124
           * Change 125 and 126 submitted to path2.
           * Path1 sync completes, path2 sync starts at 126

          The desired behavior is Path2 should be synced at 123.

           

          *Original Description:*

          HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          p4karl Karl Wirth made changes -
          Description *Karls Summary:*

          Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

          _Usage case_ - On a busy system a long running job will pickup components of different ages.

          _Example_ -
           * Poll finds latest change 123
           * Build is queued
           * Change 124 added to path1.
           * Build starts
           * Path1 synced at 124
           * Change 125 and 126 submitted to path2.
           * Path1 sync completes, path2 sync starts at 126

          The desired behavior is Path2 should be synced at 123.

           

          *Original Description:*

          HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          *Karls Summary:*

          Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

          _Usage case_ - On a busy system a long running job will pickup components of different ages.

          _Example_ -
           * Poll finds latest change 123
           * Build is queued
           * Change 124 added to path1.
           * Build starts
           * Path1 synced at 124
           * Change 125 and 126 submitted to path2.
           * Path1 sync completes, path2 sync starts at 126

          The desired behavior is path1 and path2 should be synced at 123 (if that is not possible path 2 should be synced at 124).

           

          *Original Description:*

          HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          p4karl Karl Wirth made changes -
          Description *Karls Summary:*

          Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

          _Usage case_ - On a busy system a long running job will pickup components of different ages.

          _Example_ -
           * Poll finds latest change 123
           * Build is queued
           * Change 124 added to path1.
           * Build starts
           * Path1 synced at 124
           * Change 125 and 126 submitted to path2.
           * Path1 sync completes, path2 sync starts at 126

          The desired behavior is path1 and path2 should be synced at 123 (if that is not possible path 2 should be synced at 124).

           

          *Original Description:*

          HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          *Karls Summary:*

          Polled builds (pipeline) should sync to "@now" when polling occurred not "@now" when sync occurs.

          _Usage case_ - On a busy system a long running job will pickup components of different ages.

          _Example_ -
           * Poll finds latest change 123
           * Build is queued
           * Change 124 added to path1.
           * Build starts
           * Path1 synced at 124
           * Change 125 and 126 submitted to path2.
           * Path1 sync completes, path2 sync starts at 126

          The desired behavior is path1 and path2 should be synced at 123 (if that is not possible in the Jenkins infrastructure path 1 and path2 should be synced at 124).

           

          *Original Description:*

          HI we have setup a parallel pipeline and are using SyncOnlyImpl's pin to ensure all parallel stages will build on the same changelist.

           

          Our first implementation worked as expected.  pin value was empty at first, causing it to sync to head then we extracted this value and propagated to other stages through a field.

          However other requirements required us to have that change be accessible in other parts of the build pipeline so we start the pipeline with a simple p4 command to get the head CL which is then propagated through the rest of the pipeline normally rather than through a field.

          Sync behavior is as expected where all stages sync to desired CL BUT polling is now limited by this pin value and will always check for changes using the pinned value as an upper limit.

          Net effect if this is polling still takes place but never detect any changes effectively nullifying poll behavior beyond the first run.

           

          I would expect a way to sync to a specific CL that has no side effect in other parts of the system.  Either the pin behavior is broken, or an extra parameter is required beyond pin to separate the two intent : the CL at which we wish to "pin" this job, and the CL at which we wish to sync in the populate implementation.
          p4karl Karl Wirth made changes -
          Labels P4_A P4_VERIFY P4_A
          p4karl Karl Wirth made changes -
          Assignee Karl Wirth [ p4karl ]
          p4karl Karl Wirth made changes -
          Priority Critical [ 2 ] Blocker [ 1 ]

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            newtopian Eric Daigneault
            Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated: