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 <e...@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 <e...@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 > <e...@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 > > <jaypi...@gmail.com> > > > wrote: > > > > > > > > On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger > > > > <mark.washenber...@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@lists.launchpad.net > > > > Unsubscribe : https://launchpad.net/~openstack > > > > More help : https://help.launchpad.net/ListHelp > > > > > > > _______________________________________________ > > > > Mailing list: https://launchpad.net/~openstack > > > > Post to : openstack@lists.launchpad.net > > > > Unsubscribe : https://launchpad.net/~openstack > > > > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
