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

CVS plugin queues up multiple builds on same changes when poll time < build time

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: cvs-plugin
    • Labels:
    • Environment:
      CentOS 5.5 master, Windows 7 enterprise node
    • Similar Issues:

      Description

      When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

      For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

      Started on Aug 22, 2013 9:20:58 AM
      Using locally configured password for connection to :pserver:someone@someplace:/cvshome
      cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule 
      ...
      Changes Found

      This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:

      Started on Aug 22, 2013 9:25:58 AM
      Using locally configured password for connection to :pserver:someone@someplace:/cvshome
      cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
      ...
      Changes Found

      And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log. The changes at 9:15 already successfully triggered a build into the queue, the date range of this poll should be from 9:20:58(prev) - 9:25:58(now)

      When the second build starts building, this is how it gets its changelog

      Using locally configured password for connection to :pserver:someone@someplace:/cvshome
      cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 someModule 
      

      Where 9:21:14 is the time in which the first build finished. Thus we have this "phantom build" triggered by "no changes"

      Workaround: Set polling longer interval, but this comes at the cost of responsiveness.

        Attachments

          Activity

          efusciardi Eric Fusciardi created issue -
          efusciardi Eric Fusciardi made changes -
          Field Original Value New Value
          Description When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

          For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

          {code}Started on Aug 22, 2013 9:20:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule
          ...
          Changes Found{code}
          This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:
          {code}Started on Aug 22, 2013 9:25:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
          ...
          Changes Found{code}
          And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log (because surprise, when it goes to actually execute the build, this is how it gets its change set....
          {code}Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 vp
          {code} Where 9:21:14 is the time in which the first build finished.

          Workaround: Set polling longer interval, but this comes at the cost of responsiveness.
          When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

          For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

          {code}Started on Aug 22, 2013 9:20:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule
          ...
          Changes Found{code}
          This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:
          {code}Started on Aug 22, 2013 9:25:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
          ...
          Changes Found{code}
          And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log (because surprise, when it goes to actually execute the build, this is how it gets its change set... The changes at 9:15 already successfully triggered a build into the queue, the date range of this poll should be from 9:20:58(prev) - 9:25:58(now)
          {code}Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 vp
          {code} Where 9:21:14 is the time in which the first build finished.

          Workaround: Set polling longer interval, but this comes at the cost of responsiveness.
          efusciardi Eric Fusciardi made changes -
          Description When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

          For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

          {code}Started on Aug 22, 2013 9:20:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule
          ...
          Changes Found{code}
          This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:
          {code}Started on Aug 22, 2013 9:25:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
          ...
          Changes Found{code}
          And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log (because surprise, when it goes to actually execute the build, this is how it gets its change set... The changes at 9:15 already successfully triggered a build into the queue, the date range of this poll should be from 9:20:58(prev) - 9:25:58(now)
          {code}Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 vp
          {code} Where 9:21:14 is the time in which the first build finished.

          Workaround: Set polling longer interval, but this comes at the cost of responsiveness.
          When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

          For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

          {code}Started on Aug 22, 2013 9:20:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule
          ...
          Changes Found{code}
          This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:
          {code}Started on Aug 22, 2013 9:25:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
          ...
          Changes Found{code}
          And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log. The changes at 9:15 already successfully triggered a build into the queue, the date range of this poll should be from 9:20:58(prev) - 9:25:58(now)

          When the second build starts building, this is how it gets its changelog
          {code}Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 vp
          {code} Where 9:21:14 is the time in which the first build finished. Thus we have this "phantom build" triggered by "no changes"

          Workaround: Set polling longer interval, but this comes at the cost of responsiveness.
          efusciardi Eric Fusciardi made changes -
          Description When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

          For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

          {code}Started on Aug 22, 2013 9:20:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule
          ...
          Changes Found{code}
          This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:
          {code}Started on Aug 22, 2013 9:25:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
          ...
          Changes Found{code}
          And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log. The changes at 9:15 already successfully triggered a build into the queue, the date range of this poll should be from 9:20:58(prev) - 9:25:58(now)

          When the second build starts building, this is how it gets its changelog
          {code}Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 vp
          {code} Where 9:21:14 is the time in which the first build finished. Thus we have this "phantom build" triggered by "no changes"

          Workaround: Set polling longer interval, but this comes at the cost of responsiveness.
          When CVS polling is enabled, the "high watermark" timestamp that cvs polls on for changes does not update until a build finishes. This causes multiple builds to trigger on the same changes.

          For example, a build that take 7 mins, set to poll every 5, produces the following output on its first poll.

          {code}Started on Aug 22, 2013 9:20:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:20:58 -0400 someModule
          ...
          Changes Found{code}
          This triggers a build based on changes committed at 9:15, it starts building. 5mins later this is the poll log:
          {code}Started on Aug 22, 2013 9:25:58 AM
          Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 08:30:03 -0400<22 Aug 2013 09:25:58 -0400 someModule
          ...
          Changes Found{code}
          And queues up another build based on the same changes at 9:15. This is problematic because it doubles node usage, and the second build shows nothing in it's Changes log. The changes at 9:15 already successfully triggered a build into the queue, the date range of this poll should be from 9:20:58(prev) - 9:25:58(now)

          When the second build starts building, this is how it gets its changelog
          {code}Using locally configured password for connection to :pserver:someone@someplace:/cvshome
          cvs rlog -S -d22 Aug 2013 09:21:14 -0400<22 Aug 2013 09:26:20 -0400 someModule
          {code} Where 9:21:14 is the time in which the first build finished. Thus we have this "phantom build" triggered by "no changes"

          Workaround: Set polling longer interval, but this comes at the cost of responsiveness.
          scm_issue_link SCM/JIRA link daemon made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          pelchats Simon Pelchat made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          scm_issue_link SCM/JIRA link daemon made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          theandrewducker Andrew Ducker made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          theandrewducker Andrew Ducker made changes -
          Assignee Michael Clarke [ mc1arke ]
          mc1arke Michael Clarke made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 150762 ] JNJira + In-Review [ 193661 ]

            People

            • Assignee:
              mc1arke Michael Clarke
              Reporter:
              efusciardi Eric Fusciardi
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: