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

p4-plugin 1.3.9 triggers build when there is no new changelists, and syncs to oldest changelist in the workspace

    Details

    • Similar Issues:

      Description

          • 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

        Attachments

          Activity

          Hide
          jedavis Jason Davis added a comment - - edited

          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.

          Show
          jedavis Jason Davis added a comment - - edited 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.
          Hide
          jedavis Jason Davis added a comment -

          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"

          Show
          jedavis Jason Davis added a comment - 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"
          Hide
          jedavis Jason Davis added a comment -

          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

          Show
          jedavis Jason Davis added a comment - 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
          Hide
          langtonben Ben Langton added a comment -

          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

          Show
          langtonben Ben Langton added a comment - 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
          Hide
          jedavis Jason Davis added a comment -

          Ben Langton - 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!

          Show
          jedavis Jason Davis added a comment - Ben Langton - 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!
          Hide
          p4paul Paul Allen added a comment -

          Closing old issues - presumed fixed in 1.8.x

          Show
          p4paul Paul Allen added a comment - Closing old issues - presumed fixed in 1.8.x

            People

            • Assignee:
              Unassigned
              Reporter:
              langtonben Ben Langton
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: