openstack team mailing list archive

[Trey Morris <trey.morris@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> >      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@xxxxxxxxx>
> >      >      wrote:
> >      >      >
> >      >      >      On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger
> >      >      >      <mark.washenberger@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >      >      >      Unsubscribe : https://launchpad.net/~openstack
> >      >      >      More help   : https://help.launchpad.net/ListHelp
> >      >
> >      >      > _______________________________________________
> >      >      > Mailing list: https://launchpad.net/~openstack
> >      >      > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >      >      > Unsubscribe : https://launchpad.net/~openstack
> >      >      > More help   : https://help.launchpad.net/ListHelp
>