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.