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

"Build now" should not wait for quiet period

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Trivial
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      The build now option seems to wait for a quiet period (if one is set).

      I figure that if I've clicked on Build Now, it should build NOW!

      Apart from that, it (hudson) is coming along nicely.

        Attachments

          Activity

          Hide
          lecric lecric added a comment -

          Created an attachment (id=172)
          Proposal made for adding the delay parameter to build request

          Show
          lecric lecric added a comment - Created an attachment (id=172) Proposal made for adding the delay parameter to build request
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Patch applied in 1.183.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Patch applied in 1.183.
          Hide
          bwalding Ben Walding added a comment -

          Excellent!

          Thanks for fixing.

          Show
          bwalding Ben Walding added a comment - Excellent! Thanks for fixing.
          Hide
          mb3_48900 Mircea Banu added a comment -

          I do not agree with this request.

          The delay configured via "Quiet time" must always be enforced without exception.

          If you start making exceptions (like the one proposed by the OP) things start to be confusing.

          You could at least update the description of this configuration. This is now:

          When this option is checked, newly triggered builds of this project will be added to the queue, but Jenkins will wait for the specified period of time before actually starting the build.

          For example, if your builds take a long time to execute, you may want to prevent multiple source control commits that are made at approximately the same time from triggering multiple builds. Enabling the quiet period would prevent a build from being started as soon as Jenkins discovers the first commit; this would give the developer the chance to push more commits which would be included in the build when it starts. This reduces the size of the queue, meaning that developers would get feedback faster for their series of commits, and the load on the Jenkins system would be reduced.

          If a new build of this project is triggered while a build is already sitting in the queue, waiting for its quiet period to end, the quiet period will not be reset. The newly triggered build will not be added to the queue, unless this project is parameterised and the build has different parameters to the build already in the queue.

          If this option is not checked, then the system-wide default value from the Configure System screen will be used.

          It does not say anything that by "triggered" you do not mean "triggered" by hitting "Build Now".

          By the way... is triggering a build via "Multi Job" "triggering"... or?

           

           

          Show
          mb3_48900 Mircea Banu added a comment - I do not agree with this request. The delay configured via "Quiet time" must always be enforced without exception. If you start making exceptions (like the one proposed by the OP) things start to be confusing. You could at least update the description of this configuration. This is now: When this option is checked, newly triggered builds of this project will be added to the queue, but Jenkins will wait for the specified period of time before actually starting the build. For example, if your builds take a long time to execute, you may want to prevent multiple source control commits that are made at approximately the same time from triggering multiple builds. Enabling the quiet period would prevent a build from being started as soon as Jenkins discovers the first commit; this would give the developer the chance to push more commits which would be included in the build when it starts. This reduces the size of the queue, meaning that developers would get feedback faster for their series of commits, and the load on the Jenkins system would be reduced. If a new build of this project is triggered while a build is already sitting in the queue, waiting for its quiet period to end, the quiet period will not be reset. The newly triggered build will not be added to the queue, unless this project is parameterised and the build has different parameters to the build already in the queue. If this option is not checked, then the system-wide default value from the Configure System screen will be used. It does not say anything that by "triggered" you do not mean "triggered" by hitting "Build Now". By the way... is triggering a build via "Multi Job" "triggering"... or?    
          Hide
          bwalding Ben Walding added a comment -

          This issue is 10 years old and the problem as stated was resolved.

          If you disagree with the outcome, you should raise a new ticket and link it back to this one.

          Show
          bwalding Ben Walding added a comment - This issue is 10 years old and the problem as stated was resolved. If you disagree with the outcome, you should raise a new ticket and link it back to this one.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            bwalding Ben Walding
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: