-Apache jenkins job to build release artifacts (WAS: Issue with my username on my company provided dev box?)
[Cross-posting with https://issues.apache.org/jira/browse/HADOOP-10313]
OK, we have:
* A script, create-release.sh, that creates release artifacts
* An Apache Jenkins job that runs the script and produces the artifacts in
Apache CI machines, thanks Yahoo! (or shouldn't I say that?)
The Apache Jenkins job is:
There you'll see the output of an release build. When triggering the build,
you can specify an RC_LABEL (RC0 in this case). If you do so all the
artifact files will be postfixed with it.
The job is currently producing:
* RAT report
* SOURCE tarball and its MD5
* BINARY tarball and its MD5
* SITE tarball (ready to plaster in Apache Hadoop site)
* CHANGES files
I've verified the produced SOURCE is correct and I can build a BINARY out
I've verified the produced BINARY tarball works (in pseudo-cluster mode).
Running 'hadoop-version' from the BINARY a tarball reports:
$ bin/hadoop version
Subversion http://svn.apache.org/repos/asf/hadoop/common -r 1563020
Compiled by jenkins on 2014-01-31T00:03Z
Compiled with protoc 2.5.0
From source with checksum 37ccb6f84b23196f521243fd192070
Once the JIRA is committed we have to modify the Jenkins job to use the
script from 'dev-support/' directory.
We could improve this script further to deploy the built JARs to the Maven
repo. I don't know how to do this, so it would be great if somebody that
know how jumps on that. Maybe a s a follow up JIRA, so we have something
On Thu, Jan 30, 2014 at 8:43 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
> The Apache Software Foundation takes branding seriously, we all know this.
> Making an inquiry about a possible, and I believe unintended, mis-branding
> issue involving Apache Hadoop artifacts is not a personal assault. The
> hysterical responses here have been unprofessional and disgraceful, and
> only serve to reinforce the notion people have outside your walls that you
> can't be bothered to treat the larger community with respect. That is not a
> petty issue I assure you.
> On Wed, Jan 29, 2014 at 7:31 PM, Arun C Murthy <[EMAIL PROTECTED]>
> > Stack,
> > Apologies for the late response, I just saw this.
> > On Jan 29, 2014, at 3:33 PM, Stack <[EMAIL PROTECTED]> wrote:
> > > Slightly related, I just ran into this looking back at my 2.2.0
> > >
> > > [stack@c2020 hadoop-2.2.0]$ ./bin/hadoop version
> > > Hadoop 2.2.0
> > > Subversion https://svn.apache.org/repos/asf/hadoop/common -r 1529768
> > > Compiled by hortonmu on 2013-10-07T06:28Z
> > > ...
> > >
> > > Does the apache binary have to be compiled by 'hortonmu'? Could it be
> > > compiled by 'arun', or 'apachemu'?
> > >
> > > Thanks,
> > > St.Ack
> > Thank you for tarring all my work here with a brush by insinuating not
> > sure what for using my company provided dev machine to work on Hadoop.
> > I'll try find a non-company provided dev machine to create future
> > it might take some time because I'll have to go purchase another one. Or,
> > maybe, another option is to legally change my name.
> > Meanwhile, while we are on this topic, I just did:
> > $ git clone git://git.apache.org/hbase.git
> > $ grep -ri cloudera *
> > Should I file a jira to fix all refs including the following imports of
> > org.cloudera.* (pasted below) ... can you please help fix that? There are
> > more, but I'll leave it to your discretion. Compared to my username on my
> > company provided dev. box, this seems far more egregious. Do you agree?
> > In future, it might be useful to focus our efforts on moving the project
> > forward by contributing/reviewing code/docs etc., rather than on petty
> > things like usernames.
> > thanks,
> > Arun
> > org.cloudera.htrace.Trace;