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 Plain View
Hadoop >> mail # dev >> Supporting cross-project Jenkins builds


+
Tom White 2012-04-16, 20:51
+
Aaron T. Myers 2012-04-16, 20:55
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
+
Aaron T. Myers 2012-04-16, 21:22
+
Giridharan Kesavan 2012-04-17, 22:17
+
Tom White 2012-04-17, 22:31
+
Alejandro Abdelnur 2012-04-17, 23:52
+
Giridharan Kesavan 2012-04-18, 03:36
+
Alejandro Abdelnur 2012-04-18, 17:11
+
Tom White 2012-04-25, 19:49
+
Aaron T. Myers 2012-04-18, 16:18
+
Radim Kolar 2012-04-27, 09:21
+
Tom White 2012-04-27, 23:48
+
Alejandro Abdelnur 2012-04-27, 23:52
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