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