Open Stack

Sure, that's possible too. I'll leave it to the folks setting up the
tests and working with tarmac/bzr/jenkins/... to decide what is the
easiest way to implement it. Lots of ways to do it. :)

-Eric

On Thu, Feb 24, 2011 at 06:05:48PM -0600, Trey Morris wrote:
>    can't the other tests/systems also pull the LP topic branch straight from
>    LP for testing?
>    This would allow:
>    test system 1 to pull trunk, merge topic branch A and test. if success it
>    passes it off to
>    test system 2 to pull trunk, merge topic branch A and test, while
>    test system 1 moves on, pulls trunk, merges topic branch B and tests
>    and so forth that way test system 1 isn't waiting for test system 2 to
>    finish using the test branch before it can move on to another branch. This
>    allows all the test systems to be working independently on different
>    branches.
>    On Thu, Feb 24, 2011 at 4:55 PM, Eric Day <eday at oddments.org> wrote:
> 
>      That is how it works now, but if we need to run tests that are not
>      on the tarmac machine, we need to push that local branch somewhere
>      so other things can test the same thing.
> 
>      Monty Taylor will have a much better idea of how to orchestrate all
>      of this, I'm going off what we did in the past, and I know things
>      have changed some since then.
>      -Eric
>      On Thu, Feb 24, 2011 at 04:46:28PM -0600, Trey Morris wrote:
>      >    yikes! i assumed tarmac was running things locally merged with
>      trunk to
>      >    test and actually merging after success. That's surprising. The
>      branches
>      >    would definitely be safer.
>      >
>      >    On Thu, Feb 24, 2011 at 4:41 PM, Eric Day <eday at oddments.org>
>      wrote:
>      >
>      >      Yup. Right now when a <project>-core member clicks 'Approve'
>      >      after code review, tarmac picks it up and pushes to trunk
>      assuming
>      >      unittests pass. Instead it could push to staging and trigger a
>      hook
>      >      in jenkins which would fire off a bunch of other jobs that run
>      the
>      >      staging branch through a battery of tests. If they all check out
>      ok
>      >      (possibly a human check in there to make sure variable results
>      like
>      >      performance testing are ok), staging gets pushed to the real
>      trunk.
>      >      -Eric
>      >      On Thu, Feb 24, 2011 at 04:36:16PM -0600, Trey Morris wrote:
>      >      >    I see. So their use would in general be for the use of
>      automated
>      >      systems?
>      >      >
>      >      >    On Thu, Feb 24, 2011 at 4:33 PM, Eric Day
>      <eday at oddments.org>
>      >      wrote:
>      >      >
>      >      >      The extra branches are just an implementation detail, we
>      can have
>      >      >      them or not. It's really a matter of if it's possible
>      and/or
>      >      easier
>      >      >      to have jenkins fire off new jobs with arbitrary branches
>      that
>      >      need
>      >      >      to be merged with trunk for each job vs merging and
>      pushing to a
>      >      >      staging branch and have the jobs test that. Either way, we
>      get
>      >      the
>      >      >      same result. We will also have the flexibility to test
>      arbitrary
>      >      >      branches before proposing either way. These extra "trunks"
>      will
>      >      not
>      >      >      need to be managed, as tarmac/jenkins will control them.
>      >      >      -Eric
>      >      >      On Thu, Feb 24, 2011 at 04:24:11PM -0600, Trey Morris
>      wrote:
>      >      >      >    I'm curious what the point of having a line of trunks
>      for a
>      >      commit
>      >      >      to
>      >      >      >    bounce down on its way to trunk would gain us other
>      than
>      >      having to
>      >      >      manage
>      >      >      >    a line of trunks. What's wrong with status quo branch
>      >      management
>      >      >      (other
>      >      >      >    than tests)? What's wrong with having the commit sit
>      in its
>      >      LP
>      >      >      topic
>      >      >      >    branch, which is every bit as publicly accessible as
>      any
>      >      branch in
>      >      >      the
>      >      >      >    line of trunks would be? The test system (or anyone
>      who
>      >      wants to
>      >      >      play with
>      >      >      >    it) can just grab trunk merge the topic branch and
>      run
>      >      however many
>      >      >      levels
>      >      >      >    or types of tests we deem appropriate. Success =
>      trunk. Fail
>      >      = test
>      >      >      fail
>      >      >      >    status in the test report.
>      >      >      >
>      >      >      >    On Thu, Feb 24, 2011 at 3:39 PM, Jay Pipes
>      >      <jaypipes at gmail.com>
>      >      >      wrote:
>      >      >      >
>      >      >      >      On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger
>      >      >      >      <mark.washenberger at rackspace.com> wrote:
>      >      >      >      >> This is what we're working on, and what Justin
>      is
>      >      proposing,
>      >      >      Mark.
>      >      >      >      >>
>      >      >      >      >> Basically, in Drizzle-land, people propose a
>      merge into
>      >      trunk,
>      >      >      Hudson
>      >      >      >      >> picks up that proposal, pulls the brnach into
>      >      >      lp:drizzle/staging,
>      >      >      >      >> builds Drizzle on all supported platforms (>12
>      >      OS/distro
>      >      >      combos),
>      >      >      >      then
>      >      >      >      >> runs all automated regression testing against
>      the
>      >      proposed
>      >      >      branch
>      >      >      >      (can
>      >      >      >      >> take 3 or more hours).
>      >      >      >      >>
>      >      >      >      >> We're proposing the same kind of automation for
>      >      OpenStack.
>      >      >      >      >
>      >      >      >      > Sorry, I misunderstood what Justin was proposing.
>      This
>      >      sounds
>      >      >      good to
>      >      >      >      me.
>      >      >      >      >
>      >      >      >      > We could also do this without a staging branch by
>      having
>      >      the
>      >      >      automated
>      >      >      >      system check out trunk and merge the proposed
>      branch
>      >      locally.
>      >      >      >
>      >      >      >      Sure, this is, of course, quite possible, too :)
>      >      >      >
>      >      >      >      One thing that a staging-first branch allows,
>      though, is
>      >      to set
>      >      >      up an
>      >      >      >      environment where some *very* minor or style-only
>      type
>      >      commits
>      >      >      can be
>      >      >      >      fed into trunk directly without having to got
>      through the
>      >      full
>      >      >      testing
>      >      >      >      loop...
>      >      >      >      -jay
>      >      >      >      _______________________________________________
>      >      >      >      Mailing list: https://launchpad.net/~openstack
>      >      >      >      Post to     : openstack at lists.launchpad.net
>      >      >      >      Unsubscribe : https://launchpad.net/~openstack
>      >      >      >      More help   : https://help.launchpad.net/ListHelp
>      >      >
>      >      >      > _______________________________________________
>      >      >      > Mailing list: https://launchpad.net/~openstack
>      >      >      > Post to     : openstack at lists.launchpad.net
>      >      >      > Unsubscribe : https://launchpad.net/~openstack
>      >      >      > More help   : https://help.launchpad.net/ListHelp