Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> Supporting cross-project Jenkins builds


Copy link to this message
-
Re: Supporting cross-project Jenkins builds
+1,

I'd still go a bit further in the simplification of what testpatch does.

* patches must at root level (not even try to be smart)
* all testcases should always be run (else a change in hdfs could
affect yarn/tools but not be detected, or one in yarn affect tools)

Thxs.

Alejandro

On Mon, Apr 16, 2012 at 1:55 PM, Aaron T. Myers <[EMAIL PROTECTED]> wrote:
> +1
>
> This JIRA has been sitting patch available for a few weeks:
> https://issues.apache.org/jira/browse/HADOOP-7416
>
> I don't think it's quite ready for prime time (it doesn't implement all the
> features you described) but it'd be a good starting point if someone wanted
> to take it over the finish line.
>
> --
> Aaron T. Myers
> Software Engineer, Cloudera
>
>
>
> On Mon, Apr 16, 2012 at 1:51 PM, Tom White <[EMAIL PROTECTED]> wrote:
>
>> Currently Jenkins QA builds don't support cross-project patches, since
>> they try to apply them to the hadoop-{common,hdfs,mapreduce}-project
>> tree, and reject any patches that are not strictly confined to that
>> tree. For changes that span projects (e.g. moving code from HDFS or MR
>> to Common, or build system changes) developers have to run test-patch
>> and tests manually, which is cumbersome.
>>
>> I'd like to propose that we change the Common Jenkins build so that it
>> runs from the top-level
>> (http://svn.apache.org/repos/asf/hadoop/common/trunk). The HDFS and
>> MapReduce builds would be unchanged. This would have two implications:
>> i) all patches would have to be rooted at the top-level, and ii) the
>> unit tests for all projects would be run for Common changes.
>>
>> I think i) is reasonable (and most patches are like this now) - and
>> it's easy to regenerate a patch that is rooted at the wrong level. For
>> ii), running all tests for a change in Common is probably a good thing
>> to do in general.
>>
>> Thoughts?
>>
>> Tom
>>

--
Alejandro
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB