Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-1365

Assigning of build to queues is non-optimal

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Fixed
    • 2.0 beta 3, 2.0
    • Build Queues
    • None
    • Stand Alone
      JDK 1.5.0
      Unix
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    Description

      We have a number of build queues.
      One of these queues is set to accept all plans. This is necessary so that we don't accidentally end up with a plan that cannot be built.
      Another queue is set to accept "fast builds", that is those builds which we know will be completed quickly. This, in theory, prevents the fast builds from being stuck behind a really slow build.

      The problem we run into is if 3 builds are triggered at the same time. 1 Slow, 2 Fast.
      The Slow build is assigned to the "all plans" queue.
      The 1st of the fast builds is assigned to the "fast plans" queue.
      The 2nd fast build then gets assigned to the "all plans" queue, and sits for an hour waiting for the slow build to complete.
      The 1sto f the fast builds then completes, and the "Fast queue" sits idle, while the "all plans queue" has a backlog of entries.

      Possible ways I could see this being fixed are:

      1. Don't assign a plan to a queue until the last possible minute. The plan would sit waiting for a queue to be available and would kick off as soon as an appropriate queue was empty.
      2. Allow us to create a queue which said "All plans except..." then we could still have our catch-all queue ready for new plans, but not allow our slow builds to run on it.
      3. When choosing a queue to which to add the plan, look at the estimated time remaining for the already queued builds.

      Attachments

        Activity

          People

            Unassigned Unassigned
            b605b5a5aef2 Tim Vernum
            Votes:
            4 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: