Hi all here, we are looking at looking at implementing this. The idea behind the methodology adopted here was if you are only ever going to sync to a particular CL in the past, why do want to poll to the latest and keep building the same thing over and over.

Can all the watchers here document a few cases from their own usages, it would help us prioritize this. 
Many thanks in advance!

Please have a look at the summay at JENKINS-63879. The point is that you want to ensure that multiple build paths - as part of the pipeline - will synch to the same source code state.

For my part I have a lot of Linux build nodes and only a few Windows build nodes. So if the pipeline requires to build for both platforms then the Linux part might start early and the Windows part might start an hour later.

To my knowledge there is no way beside using a pinned build to ensure that both parts use the same source code state. And beyond that: if I have later steps depending on the initial build result - e.g. starting a Coverity build or  starting UI tests on a different system only if building itself has passed then I also need to make sure that the same source code state is used.

Okay, one could use stashing ... but that is far too slow with Jenkins. Especially when having a build node inside Azure with a local P4 proxy and the CI server locally.

So ... currently I cannot do incremental builds due to this problem.

Please also see for

• the communication as part of case #00863974 as of March
• JENKINS-71364
• JENKINS-71143

Hi Saurabh,

is fixing this problem now part of your current sprint? Or if not: when can we expect this to be fixed?

Hi heiko_nardmann we are currently actively working on this and another issue and should be out with a release within the next couple of weeks. Will update this if anything changes. Thanks for the use case and the assist on this.

Hi Saurabh,

after more than a month now since your last statement I wonder whether there are any news wrt. a new plugin release?

Hi heiko_nardmann the developers were stuck with a difficult problem in another product. We are now back to P4 plugin on Jenkins and actively working this. The plan as mentioned earlier is to allow for an option in the SCM checkout step (along with the existing polling related options like polling latest change). While the development effort on this is relatively lesser, we will be spending time testing out the very many scenarios possible. We would like to share a preview build for your feedback as well, if you can share any issues you see, it would be helpful, expect an update in the next week. Thanks!

Feel free to provide me some beta version: I can test this then on the weekend and revert back to the official release in case of trouble.

Luckily many scenarios are already part of the automated test cases.

Hi heiko_nardmann Karl has very kindly created a case for us to share the preview hpi file. Hope you have received it and are able to install it. While we do not expect this fix to have a drastic impact on any environment but of course it would be prudent to try this out in a non-risky scenario. Hoping to hear from you. Many thanks again!

Hi, in P4 plugin 1.14.3 release, we have added a new polling build filter - 'Polling latest change with pin' which when enabled, overrides the pin in the checkout step and polls to 'now'
Closing this

Please don't forget to update the corr. documentation: my search for "latestWithPin" did not show up any hit inside the *.md files.