I came to log a possibly related bug in 1.3.9 - or what sounds like another side effect of this noticed problem. If it's not related, I'd be happy to create a new issue.

In my case, I'm doing a clean workspace wipe and force sync and I want the build to sync to the latest revision when the job finally kicks off and builds, however, the build is NOT syncing to the latest available change, it's instead syncing to the latest available change that triggered the build.

What appears to be happening is that when the build is polling for changes and when it finds one it enters the queue and starts to build. If another build is triggered by a change while the first is building, the second build appears to remember the change that triggered itself and then sync to that level. That makes some sense, but there may be many other changes that are checked after the point the job enters the queue while it waits. Those other changes are not being synced when the second build finally starts.

For me this is causing multiple problems, it's confusing users, because they expect their changes in the build that initiated after their checkin and not all of them are showing up. Additionally, in my environment, builds are actually doing some updates on files and checking those into perforce for subsequent builds. Because in some cases those updates are occurring after the second build is triggered, the second build is syncing the previous version of those files and causing a reconcile situation when it tries to submit it's own config changes to perforce. The reconcile step is causing all sorts of builds to fail and folks think that there's something corrupted with Jenkins, the process, or the build workspace.

Rolling back to 1.3.8 fixed the problem and enabled the build to sync to the latest change, but if syncing to the change that triggered a build is by design, then it appears I need a "sync to latest available change at build time" option in the plugin configuration, or I'll have to come up with a new way to manage my builds.

In case it matters, I'm also syncing multiple top level depot paths with a manual workspace view set in the job definition and setting the three populate options: populate have list, sync with modtime, and quiet messages.

Hi there - just curious if this issue has been considered recently. I'd love to upgrade from 1.3.8, but this issue is actually a blocker since I can't achieve a good build without getting the latest files available when the build actually starts.

It looks like maybe this change in 1.4.2 might help, but it's difficult to know.

"Add checks for sync CL and head CL"

After more testing with 1.4.3 I was able to more readily track down the problem I was experiencing. This issue still sounds like it's related, but it's not seemingly the same as described here, so I logged a new issue for tracking there:

JENKINS-36883

I was able to work around this issue in 1.4.3, by using the new "Poll on Master using Last Build" option.
Thanks!
Ben Langton

langtonben - I tested with the workaround to see if it might help my issue also, but unfortunately I'm still getting the same behavior syncing filtered files. Much appreciated though!

Closing old issues - presumed fixed in 1.8.x