• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • other
    • None
    • Platform: All, OS: All

      We have upgraded from Hudson 1.224 to 1.244.
      We had projects set to a quiet period of 2 minutes. And we have svn update
      polling every minute.

      We kept this configuration, but this caused the builder not to build at all. It
      kept the job in the queue for every. It got reset every time (also without
      check-ins).
      We had to remove the quiet period to get it building.

          [JENKINS-2180] Quiet period keeps running without building

          dgreen added a comment -

          we have also experienced the same problem.

          dgreen added a comment - we have also experienced the same problem.

          acronce added a comment -

          I just ran into the same problem where we had our polling interval set to a minute, and a quiet period set
          to 10 minutes. This seems like a reasonable configuration, but builds are getting stuck.

          acronce added a comment - I just ran into the same problem where we had our polling interval set to a minute, and a quiet period set to 10 minutes. This seems like a reasonable configuration, but builds are getting stuck.

          dgreen added a comment -

          as a workaround what we've done is eliminate the quite period and set the polling interval to what was
          previously the quiet period. This doesn't have exactly the same effect, but for our purposes it has worked
          pretty well so far.

          dgreen added a comment - as a workaround what we've done is eliminate the quite period and set the polling interval to what was previously the quiet period. This doesn't have exactly the same effect, but for our purposes it has worked pretty well so far.

          Alan Harder added a comment -

          Copying my comment from related issue #2671:

          I can confirm this behavior. What's happening:

          In case of equal SCM-poll schedule and quiet period: initial quiet period ends
          and a build starts, and at the same time another SCM-poll starts. The SCM-poll
          thinks there are still new changes because it runs before the new build has a
          chance to update the job workspace with the latest changes from the repository.
          So that build runs AND a new one is scheduled (quiet period begins).

          Another variation: if the quiet period is slightly longer than the SCM poll
          schedule then a build never starts.. every SCM poll sees new changes and then
          extends the quiet period of the waiting job, so the quiet period never completes.

          WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds
          shorter than any SCM-polling schedule/interval (however long SCM updates take).
          This gives the newly-started job time to update the job workspace before the
          next SCM poll.

          SOLUTION for these issues? Not sure.. perhaps some locking on the SCM-poll to
          prevent it from running if a build has started, but not yet updated the
          workspace. There's already some locking code around SCM-poll, so maybe it could
          be updated for this case.
          For the 2nd variation, there are a few options:

          • don't extend quiet period.. this would allow a build to start. easiest to
            implement; small change in Queue.add()
          • to keep extend-QP the SCM-poll would need some way to distinguish
            changes-vs-job-workspace from changes-since-last-poll, and only extend quiet
            period for the latter. not sure how this would work..

          Alan Harder added a comment - Copying my comment from related issue #2671: I can confirm this behavior. What's happening: In case of equal SCM-poll schedule and quiet period: initial quiet period ends and a build starts, and at the same time another SCM-poll starts. The SCM-poll thinks there are still new changes because it runs before the new build has a chance to update the job workspace with the latest changes from the repository. So that build runs AND a new one is scheduled (quiet period begins). Another variation: if the quiet period is slightly longer than the SCM poll schedule then a build never starts.. every SCM poll sees new changes and then extends the quiet period of the waiting job, so the quiet period never completes. WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds shorter than any SCM-polling schedule/interval (however long SCM updates take). This gives the newly-started job time to update the job workspace before the next SCM poll. SOLUTION for these issues? Not sure.. perhaps some locking on the SCM-poll to prevent it from running if a build has started, but not yet updated the workspace. There's already some locking code around SCM-poll, so maybe it could be updated for this case. For the 2nd variation, there are a few options: don't extend quiet period.. this would allow a build to start. easiest to implement; small change in Queue.add() to keep extend-QP the SCM-poll would need some way to distinguish changes-vs-job-workspace from changes-since-last-poll, and only extend quiet period for the latter. not sure how this would work..

          Alan Harder added a comment -
              • Issue 2382 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2382 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment -
              • Issue 2626 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2626 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment -
              • Issue 2530 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2530 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment -
              • Issue 2416 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2416 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment -
              • Issue 2240 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2240 has been marked as a duplicate of this issue. ***

          aebbert added a comment -

          Going on cc: to track when this issue is fixed. Same problem for us. We used the
          quiet period to hold the Naginator Plugin from building every 5 seconds, but we
          have to disable Naginator and quiet period for now.

          aebbert added a comment - Going on cc: to track when this issue is fixed. Same problem for us. We used the quiet period to hold the Naginator Plugin from building every 5 seconds, but we have to disable Naginator and quiet period for now.

          maxence added a comment -

          Ran through the same issue, I had the quiet period set to 5 minutes and my jobs
          weren't building after a SCM change. Set the quiet period to 0 and jobs started
          building.

          It seems that the quiet period feature is not really working as it is, or at
          least confusing without further explanation.

          Until a fix is found (I understand it's not trivial), wouldn't be a good idea to
          remove this feature from the web UI, or at least to put a warning in the help
          tooltip ?

          This is the only issue that prevented Hudson from working out-of-the-box for me,
          and I believe many users have or will bump into the same issue.

          PS: great job guys, I'm really impressed!

          maxence added a comment - Ran through the same issue, I had the quiet period set to 5 minutes and my jobs weren't building after a SCM change. Set the quiet period to 0 and jobs started building. It seems that the quiet period feature is not really working as it is, or at least confusing without further explanation. Until a fix is found (I understand it's not trivial), wouldn't be a good idea to remove this feature from the web UI, or at least to put a warning in the help tooltip ? This is the only issue that prevented Hudson from working out-of-the-box for me, and I believe many users have or will bump into the same issue. PS: great job guys, I'm really impressed!

          mcpdr added a comment -

          added myself to the cc for this issue.

          Any idea when this issue might be fixed? This is the only issue we have had
          with Hudson. We are trying to manage multiple interdependant projects, which
          is difficult with this issue. It causes many false broken build messages, as
          it starts the build before the proper time, particularly on large, multi-step
          checkins.

          mcpdr added a comment - added myself to the cc for this issue. Any idea when this issue might be fixed? This is the only issue we have had with Hudson. We are trying to manage multiple interdependant projects, which is difficult with this issue. It causes many false broken build messages, as it starts the build before the proper time, particularly on large, multi-step checkins.

          Alan Harder added a comment -

          first comment: if having a quiet period would be helpful but you've hit this
          issue, consider raising your SCM polling interval rather than lowering or
          removing the quiet period. for example, if you need a 10 minute quiet period
          then set your SCM polling interval to 15 minutes.

          second comment: would anyone object to never extending the quiet period? ie, if
          your QP is 10 minutes and a build is triggered then it will start in 10 minutes,
          even if new SCM changes come in during that time. The reason this issue is not
          fixed yet is that it is very non-trivial to determine if a detected SCM change
          is new vs the workspace or new vs the last poll, and would likely require coding
          for each SCM system. It is far, far easier to simply not extend the QP when a
          build is re-triggered. Please comment whether this sounds acceptable, or
          explain your use case where extending the QP is important (I can see it being
          convenient if you checkin several things in sequence, but if that is common you
          can just set the QP to 15-30 minutes or something).

          Alan Harder added a comment - first comment: if having a quiet period would be helpful but you've hit this issue, consider raising your SCM polling interval rather than lowering or removing the quiet period. for example, if you need a 10 minute quiet period then set your SCM polling interval to 15 minutes. second comment: would anyone object to never extending the quiet period? ie, if your QP is 10 minutes and a build is triggered then it will start in 10 minutes, even if new SCM changes come in during that time. The reason this issue is not fixed yet is that it is very non-trivial to determine if a detected SCM change is new vs the workspace or new vs the last poll, and would likely require coding for each SCM system. It is far, far easier to simply not extend the QP when a build is re-triggered. Please comment whether this sounds acceptable, or explain your use case where extending the QP is important (I can see it being convenient if you checkin several things in sequence, but if that is common you can just set the QP to 15-30 minutes or something).

          jdruce added a comment -

          When we set the quiet period to 5 minutes and the polling to 6 minutes, it does
          not detect any checkins done inside the 5 minute quiet period. I would assume
          that as soon as something is checked in inside the quiet period that the
          counter would reset to 5 minutes again. It appears this is not happening.

          jdruce added a comment - When we set the quiet period to 5 minutes and the polling to 6 minutes, it does not detect any checkins done inside the 5 minute quiet period. I would assume that as soon as something is checked in inside the quiet period that the counter would reset to 5 minutes again. It appears this is not happening.

          Alan Harder added a comment -

          @jdruce: that's right.. please see "second comment" above. It is not easy to
          detect more checkins during the quiet period. Right now it can't distinguish
          the original checkin from an additional one, so if your poll interval is < quiet
          period then it keeps extending the QP forever. I'm recommending never extending
          the QP, so a build will always start after N minutes regardless of whether your
          QP is shorter or longer than the SCM poll interval.

          Alan Harder added a comment - @jdruce: that's right.. please see "second comment" above. It is not easy to detect more checkins during the quiet period. Right now it can't distinguish the original checkin from an additional one, so if your poll interval is < quiet period then it keeps extending the QP forever. I'm recommending never extending the QP, so a build will always start after N minutes regardless of whether your QP is shorter or longer than the SCM poll interval.

          gj added a comment -

          just adding myself to the cc list

          gj added a comment - just adding myself to the cc list

          mdonohue added a comment -

          This issue appears to be the flipside of issue 1737.

          The suggestion from June 6 would be to revert the behavior thats in Hudson now.
          I think we can provide a more fine-grained approach, by adding a method like
          'supportsIncrementalPolling' to hudson.scm.SCM, which would default to false -
          matching what most SCM plugins do today. If a SCM can do polling from the
          last poll, instead of from the last build, it would return 'true' for
          incremental polling.

          When incremental polling is available for an SCM, the quiet period would work as
          specified in issue 1737. When incremental polling is not available, the quiet
          period would just become a build delay.

          mdonohue added a comment - This issue appears to be the flipside of issue 1737. The suggestion from June 6 would be to revert the behavior thats in Hudson now. I think we can provide a more fine-grained approach, by adding a method like 'supportsIncrementalPolling' to hudson.scm.SCM, which would default to false - matching what most SCM plugins do today. If a SCM can do polling from the last poll, instead of from the last build, it would return 'true' for incremental polling. When incremental polling is available for an SCM, the quiet period would work as specified in issue 1737. When incremental polling is not available, the quiet period would just become a build delay.

          dominikg added a comment -

          just ran into this on hudson 1.334 the other day and would like to see it fixed.

          Another possible workaround for svn users could be to use a polling frequency of
          @yearly and setup a post-commit hook to notify hudson[1]. That way, quiet period
          should only be extended if a new commit happens.

          regards,
          Dominik

          [1] http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

          dominikg added a comment - just ran into this on hudson 1.334 the other day and would like to see it fixed. Another possible workaround for svn users could be to use a polling frequency of @yearly and setup a post-commit hook to notify hudson [1] . That way, quiet period should only be extended if a new commit happens. regards, Dominik [1] http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

          Code changed in hudson
          User: : kohsuke
          Path:
          http://fisheye4.cenqua.com/changelog/hudson/?cs=24266
          Log:
          Creating a branch to play with a possible fix for JENKINS-2180.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://fisheye4.cenqua.com/changelog/hudson/?cs=24266 Log: Creating a branch to play with a possible fix for JENKINS-2180 .

          Code changed in hudson
          User: : kohsuke
          Path:
          http://fisheye4.cenqua.com/changelog/hudson/?cs=24270
          Log:
          Branching the subversion plugin to make sure the fix for JENKINS-2180 works with a real-world SCM.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://fisheye4.cenqua.com/changelog/hudson/?cs=24270 Log: Branching the subversion plugin to make sure the fix for JENKINS-2180 works with a real-world SCM.

          Proposed change implemented and subversion/mercurial plugins are branched out to test this.

          Remaining work:

          • Look at test failures
          • Add a few more tests to verify the behavior
          • merge and release

          Kohsuke Kawaguchi added a comment - Proposed change implemented and subversion/mercurial plugins are branched out to test this. Remaining work: Look at test failures Add a few more tests to verify the behavior merge and release

          Code changed in hudson
          User: : kohsuke
          Path:
          http://jenkins-ci.org/commit/27086
          Log:
          Initialized merge tracking via "svnmerge" with revisions "1-27085" from
          https://www.dev.java.net/svn/hudson/branches/JENKINS-2180

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27086 Log: Initialized merge tracking via "svnmerge" with revisions "1-27085" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180

          Code changed in hudson
          User: : kohsuke
          Path:
          http://jenkins-ci.org/commit/27088
          Log:
          Initialized merge tracking via "svnmerge" with revisions "1-24268" from
          https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/main

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27088 Log: Initialized merge tracking via "svnmerge" with revisions "1-24268" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/main

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/main/core/src/main/java/hudson/fsp/WorkspaceSnapshotSCM.java
          trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
          trunk/hudson/main/core/src/main/java/hudson/scm/NullSCM.java
          trunk/hudson/main/core/src/main/java/hudson/scm/SCM.java
          trunk/hudson/main/test/src/test/groovy/hudson/cli/BuildCommandTest.groovy
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/27103
          Log:
          [FIXED JENKINS-2180] revised the design of polling to fix the problem.
          See:

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/core/src/main/java/hudson/fsp/WorkspaceSnapshotSCM.java trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java trunk/hudson/main/core/src/main/java/hudson/scm/NullSCM.java trunk/hudson/main/core/src/main/java/hudson/scm/SCM.java trunk/hudson/main/test/src/test/groovy/hudson/cli/BuildCommandTest.groovy trunk/www/changelog.html http://jenkins-ci.org/commit/27103 Log: [FIXED JENKINS-2180] revised the design of polling to fix the problem. See:

          Code changed in hudson
          User: : kohsuke
          Path:
          http://jenkins-ci.org/commit/27142
          Log:
          Initialized merge tracking via "svnmerge" with revisions "1-24270" from
          https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27142 Log: Initialized merge tracking via "svnmerge" with revisions "1-24270" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/plugins/mercurial/pom.xml
          trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialSCM.java
          trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialTagAction.java
          http://jenkins-ci.org/commit/27484
          Log:
          Merged revisions 27063,27067 via svnmerge from
          https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/plugins/mercurial/pom.xml trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialSCM.java trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialTagAction.java http://jenkins-ci.org/commit/27484 Log: Merged revisions 27063,27067 via svnmerge from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial

          Code changed in hudson
          User: : kohsuke
          Path:
          http://jenkins-ci.org/commit/27483
          Log:
          Initialized merge tracking via "svnmerge" with revisions "1-27061" from
          https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: http://jenkins-ci.org/commit/27483 Log: Initialized merge tracking via "svnmerge" with revisions "1-27061" from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/mercurial

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/plugins/subversion/pom.xml
          trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionSCM.java
          trunk/hudson/plugins/subversion/src/test/java/hudson/scm/SubversionSCMTest.java
          http://jenkins-ci.org/commit/27482
          Log:
          Merged revisions 24271,27060,27064 via svnmerge from
          https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/plugins/subversion/pom.xml trunk/hudson/plugins/subversion/src/main/java/hudson/scm/SubversionSCM.java trunk/hudson/plugins/subversion/src/test/java/hudson/scm/SubversionSCMTest.java http://jenkins-ci.org/commit/27482 Log: Merged revisions 24271,27060,27064 via svnmerge from https://www.dev.java.net/svn/hudson/branches/JENKINS-2180/subversion

          adrian_ added a comment - - edited

          As of the 1.346 release notes this should be resolved, but isn't.

          It's still the same behavior as before. The period is reseted after each svn check, even if there where no changes.

          adrian_ added a comment - - edited As of the 1.346 release notes this should be resolved, but isn't. It's still the same behavior as before. The period is reseted after each svn check, even if there where no changes.

          Alan Harder added a comment -

          I also thought this was a bit premature to go in the changelog.. the core support was added, but SCM plugins must then be updated to use it. So you need 1.346+ and the next release of Subversion plugin (I don't know the ETA on that).

          Alan Harder added a comment - I also thought this was a bit premature to go in the changelog.. the core support was added, but SCM plugins must then be updated to use it. So you need 1.346+ and the next release of Subversion plugin (I don't know the ETA on that).

          mdonohue added a comment -

          > If this should be the expected behavior I don't know what's this feature good for.

          I find this comment to be entirely antagonistic for no reason. Some humility when asking for help goes a long way.

          mdonohue added a comment - > If this should be the expected behavior I don't know what's this feature good for. I find this comment to be entirely antagonistic for no reason. Some humility when asking for help goes a long way.

          adrian_ added a comment -

          @mdonohue

          You are right. I removed it.

          adrian_ added a comment - @mdonohue You are right. I removed it.

          Alan Harder added a comment -

          Marking as resolved again, now that subversion plugin 1.12 has been released.

          Alan Harder added a comment - Marking as resolved again, now that subversion plugin 1.12 has been released.

          I'm seeing this issue - or something very like it with CVS on Jenkins version 1.414, CVS Plugin 1.4

          I had polling turned on in my CI projects but with a blank poll schedule. I wanted to enable polling but not actually do it. Once I realized what was going on, I set the polling schedule to once a day but still saw this behavior. Even tried restarting Jenkins in the hopes that it would clear any cobwebs or old polling threads with a bad schedule, but still saw the behavior.
          It didn't resolve until I disabled polling altogether.

          G. Ann Campbell added a comment - I'm seeing this issue - or something very like it with CVS on Jenkins version 1.414, CVS Plugin 1.4 I had polling turned on in my CI projects but with a blank poll schedule. I wanted to enable polling but not actually do it. Once I realized what was going on, I set the polling schedule to once a day but still saw this behavior. Even tried restarting Jenkins in the hopes that it would clear any cobwebs or old polling threads with a bad schedule, but still saw the behavior. It didn't resolve until I disabled polling altogether.

          Sorry if you get this twice - I just posted to the issue before re-opening. I am seeing this behavior on Jenkins 1.414 & CVS plugin 1.4.

          I merely had polling enabled in the CI jobs, but with no schedule & a 5-min. quiet period. Jobs would tick down the quiet period to just under a minute, then reset. Checking the access logs showed no additional CI triggers.

          Setting a daily poll cron still didn't help. I finally disabled polling altogether & finally saw jobs finishing their quiet periods and building.

          I'll be happy to provide whatever system information you need.

          G. Ann Campbell added a comment - Sorry if you get this twice - I just posted to the issue before re-opening. I am seeing this behavior on Jenkins 1.414 & CVS plugin 1.4. I merely had polling enabled in the CI jobs, but with no schedule & a 5-min. quiet period. Jobs would tick down the quiet period to just under a minute, then reset. Checking the access logs showed no additional CI triggers. Setting a daily poll cron still didn't help. I finally disabled polling altogether & finally saw jobs finishing their quiet periods and building. I'll be happy to provide whatever system information you need.

          Alan Harder added a comment -

          This was a long running issue and I'd rather not see it reopened. I believe the problem is the newer polling API was implemented for subversion plugin but probably not for CVS. Please file a new feature request asking for new polling API support in CVS plugin, thanks!

          Alan Harder added a comment - This was a long running issue and I'd rather not see it reopened. I believe the problem is the newer polling API was implemented for subversion plugin but probably not for CVS. Please file a new feature request asking for new polling API support in CVS plugin, thanks!

          I'm still seeing this issue using Jenkins 1.596.2 and Subversion plugin 2.5.
          Quiet period is set to 900 seconds, SCM polling is done every minute.
          Jenkins is always showing "(pending—In the quiet period. Expires in 14 min)".

          Am I doing something wrong?

          Patric Rufflar added a comment - I'm still seeing this issue using Jenkins 1.596.2 and Subversion plugin 2.5. Quiet period is set to 900 seconds, SCM polling is done every minute. Jenkins is always showing "(pending—In the quiet period. Expires in 14 min)". Am I doing something wrong?

          Daniel Beck added a comment -

          mineralwasser:

          Am I doing something wrong?

          I see the same issue (on 1.565.3 as well). Please file a new issue about this against the core component and assign it to me, I'll look into it.

          Daniel Beck added a comment - mineralwasser : Am I doing something wrong? I see the same issue (on 1.565.3 as well). Please file a new issue about this against the core component and assign it to me, I'll look into it.

          Code changed in jenkins
          User: Daniel Beck
          Path:
          core/src/main/java/hudson/model/Queue.java
          http://jenkins-ci.org/commit/jenkins/1072f5c1372d2884beb07c9114b9b90ce0bf037e
          Log:
          JENKINS-2180 Always use earlier scheduling date.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: core/src/main/java/hudson/model/Queue.java http://jenkins-ci.org/commit/jenkins/1072f5c1372d2884beb07c9114b9b90ce0bf037e Log: JENKINS-2180 Always use earlier scheduling date.

          Code changed in jenkins
          User: Daniel Beck
          Path:
          core/src/main/java/hudson/model/Queue.java
          http://jenkins-ci.org/commit/jenkins/c9c62d3681460d4898f26e8fe07b9d4fc80f40e7
          Log:
          Merge pull request #1665 from daniel-beck/JENKINS-2180

          JENKINS-2180 Always use earlier scheduling date.

          Compare: https://github.com/jenkinsci/jenkins/compare/8c5b9cd008a4...c9c62d368146

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: core/src/main/java/hudson/model/Queue.java http://jenkins-ci.org/commit/jenkins/c9c62d3681460d4898f26e8fe07b9d4fc80f40e7 Log: Merge pull request #1665 from daniel-beck/ JENKINS-2180 JENKINS-2180 Always use earlier scheduling date. Compare: https://github.com/jenkinsci/jenkins/compare/8c5b9cd008a4...c9c62d368146

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4189
          JENKINS-2180 Always use earlier scheduling date. (Revision 1072f5c1372d2884beb07c9114b9b90ce0bf037e)

          Result = UNSTABLE
          daniel-beck : 1072f5c1372d2884beb07c9114b9b90ce0bf037e
          Files :

          • core/src/main/java/hudson/model/Queue.java

          dogfood added a comment - Integrated in jenkins_main_trunk #4189 JENKINS-2180 Always use earlier scheduling date. (Revision 1072f5c1372d2884beb07c9114b9b90ce0bf037e) Result = UNSTABLE daniel-beck : 1072f5c1372d2884beb07c9114b9b90ce0bf037e Files : core/src/main/java/hudson/model/Queue.java

            kohsuke Kohsuke Kawaguchi
            cbos Cees Bos
            Votes:
            19 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: