Status: Closed (View Workflow)
Resolution: Cannot Reproduce
Perforce Server Server 2013.2
- Update: This issue occurs on plugin version 1.4.0, as well.
Issue begins immediately after upgrading p4-plugin to 1.3.9, and goes away as soon as I downgrade to 1.3.8 (I tried it multiple times). I verified that the workspace was at the latest revision, and cstat reported status "have" for all changelists, before upgrading the plugin.
I have several jobs that poll Perforce for changes; all are affected. Polling triggers a build when there are no new changes. When the build syncs the workspace, it syncs not to the latest changelist, but to what I think is the oldest changelist containing files from the workspace.
I think this is because it is not correctly parsing the status field returned from cstat, when it polls. Polling log is attached. It says "found change" on changelists that cstat reported were status "have" (I ran it independently of Jenkins) immediately prior to upgrading the plugin.
Here is part of the build console output that demonstrates the issue; the raw text is attached. The latest changelist is 605049, but it syncs to changelist 530996
p4 changes -m1 -ssubmitted //FmsDbPatches_P4Poll/...
Change 605049 on 2016/05/18 by jwb@jwb-netmenu 'MDIA - Edit Service Menus: Menu'
P4 Task: syncing files at change: 530996
p4 sync D:\Workspaces\FmsDbPatches_P4Poll/...@530996
D:\Workspaces\FmsDbPatches_P4Poll/...@530996 - file(s) up-to-date.
... p4 changes -m100 //FmsDbPatches_P4Poll/...@605008,530996
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:
I was able to work around this issue in 1.4.3, by using the new "Poll on Master using Last Build" option.
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!
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.