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

Use previous project rather than SCM to bootstrap a plan

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Won't Do
    • None
    • Builds
    • None
    • 0
    • 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

      This is closely related to BAM-2525, and might be considered another way of providing the same end-user functionality.

      Essentially, instead of saying that I should load things from my underlying SCM system (P4, SVN, etc.), I say "use this other plan" (PlanA).

      Then, when my child plan (PlanB), which uses this bootstrapping system kicks off, it pulls down a fork/copy of the entire state of the previous plan's state and uses that for the build area, rather than populating from the underlying SCM system.

      I prefer this to BAM-2525, for the following reasons:
      1) It allows me to support faster PlanA changes than PlanB changes.
      For example, assume that PlanA is a build, PlanB is a quick test suite, and PlanC is a comprehensive test suite. I can do 10 PlanA builds, and 3 PlanB builds for 1 PlanC build. I really don't care about the PlanA artifacts that I'm not using for PlanB (and thus PlanC), and I'd prefer not to even keep them around.

      2) It allows me to actually build PlanA faster
      Again, consider a Build/Quick/Full pattern. In this case, I don't want to share the build area, because then I HAVE to block PlanA while PlanB and PlanC run. That's terrible if PlanA takes 5 minutes, PlanB takes 10 minutes, and PlanC takes 4 hours (not an uncommon case here). I'd much prefer to be able to keep PlanA chugging along and giving people build success notifications while everybody waits for the PlanC results (which are the super-slow ones that nobody wants to wait for just to find out if they've broken the build).

      3) It supports multiple agents
      If I share build area, under the current model, everything would have to be on the same build agent. That doesn't work for me in a multi-test scenario:
      PlanA is my build
      PlanB is test on Linux (depends on PlanA)
      PlanC is test on Windows (also depends on PlanA)
      PlanD is test on Solaris in London (also depends on PlanA)
      PlanE is test on Solaris in New York (also depends on PlanA)

      If I have to share a build area, I can't support this model.

      Even without multiple independent builds dependent on the same source, I'd MUCH prefer to be able to allocate my agents by response time: allocate a 16-core machine to C++ builds where I need instantaneous developer response, and allocate slower machines to running tests where I don't need as fast a response.

      In summary: Forking is better than sharing.

      Attachments

        Activity

          People

            Unassigned Unassigned
            aca233f59075 Kirk Wylie
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: