Thanks Giri. > Longterm solution: > email patch process and queue creation is un-reliable. As a long term > solution we need to use jira-cli command line tool to read patch directly > from jira.
Ya, that's what I've got mostly working on my machine. Any open Jira's for this work? If not, I'll open one. > And doing this would require introducing a new workflow in jira. Apart from > the current status called "patch-available" Not sure that's necessary. I think if we change the patch testing model a little, we can keep the current workflow. Also, given some recent advances in Hudson, I think we can reduce all the patch jobs down to 1 admin job covering *all* projects and 1 job per project -- and we should be able to drastically improve utilization of the slaves we have. Let's move this discussion to a ticket. LMK if I need to open one. Cheers, Nige On Oct 20, 2010, at 1:17 PM, Giridharan Kesavan wrote: > > Old times: > The hudson patch-testing admin job used to run on the master machine > hudson.zones.apache.org as this machine used to parse the emails from jira > and create the patch queue for testing. > > Current situation: > hudson.zones.apache.org machine is no more a master and we have a new machine > called aegis.apache.org as the master machine. > > This machine is configured to process the email and create the patch queue. > <done> > Though we are able to get the email and create the patch queue on the new > aegis.apache.org machine, still we wont be able to trigger patch admin job on > the hudson master as this is not allowed in the new setup. > > Infra team doesn't want us to run any builds on the hudson master. Instead > they want all the builds to run on the slave machine. > > I got the password-less access for hudson user from hudson slave > h1.grid.sp2.yahoo.net to aegis.apache.org like 2 weeks back. <done> > > The plan here is to read the patch queue on aegis from h1 and schedule > builds. <I'm working on getting this to work> > > Longterm solution: > email patch process and queue creation is un-reliable. As a long term > solution we need to use jira-cli command line tool to read patch directly > from jira. > And doing this would require introducing a new workflow in jira. Apart from > the current status called "patch-available" > > Thanks, > Giri > > On Oct 20, 2010, at 12:54 PM, Konstantin Boudnik wrote: > >> Thanks for getting to it, Nigel. This is absolutely useful and allows to keep >> weeds out of the trunk up to a certain degree. >> >> There were at least two slightly different sources of information about >> what's >> going on with test-patch process. Would you mind to post a brief about the >> situation so comments can be more substantial? >> >> Thanks, >> Cos >> >> On Wed, Oct 20, 2010 at 12:47PM, Nigel Daley wrote: >>> Folks, >>> >>> I'm working to get the pre-commit patch testing running again for HDFS, >>> HADOOP, and MAPREDUCE patches. Since I've been on a bit of a hiatus from >>> day-to-day involvement w/ the project over the last 6 months (new job), I >>> want to check in and make sure folks would still find this pre-commit >>> testing useful. Also, happy to hear any suggested improvement. Let me >>> know. >>> >>> Cheers, >>> Nige >
