hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13525) Update test-patch to leverage Apache Yetus
Date Fri, 08 Jan 2016 00:38:39 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088484#comment-15088484

Sean Busbey commented on HBASE-13525:

bq. Suggest hoisting your how-to-run-it up to release note.

will do.

bq. Is test-patch missing from this patch? I see this patch removes test-patch.sh but it does
not seem to include test-patch.

Not included. this patch presumes folks using it will install Yetus' test-patch. The rewritten
jenkins job, for example, keeps a cached install of the latest release. I'll include a link
to "download yetus" in the release note to mitigate?

something like

You'll need a local installation of [Apache Yetus' precommit checker](http://yetus.apache.org/documentation/0.1.0/#yetus-precommit)
to use this personality.

Download from: http://yetus.apache.org/downloads/ . You can either grab the source artifact
and build from it, or use the convenience binaries provided on that download page.

To run against, e.g. HBASE-15074 you'd then do
test-patch --personality=dev-support/hbase-personality.sh HBASE-15074

If you want to skip the ~1 hour it'll take to do all the hadoop API checks, use
test-patch  --plugins=all,-hadoopcheck --personality=dev-support/hbase-personality.sh HBASE-15074

pass the `--jenkins` flag if you want to allow test-patch to destructively alter local working
directory / branch in order to have things match what the issue patch requests.

I see this in personality:
So, how do I run a patch against an old branch now? Does the trick where you add the branch
name to the patch name work still?

Yep. It works now for arbitrary branches/refs found in the repo, not just a whitelist. https://yetus.apache.org/documentation/0.1.0/precommit-patchnames/

This list is impressive but a little OCD: 54 + HBASE_HADOOP_VERSIONS="2.4.0 2.4.1 2.5.0 2.5.1
2.5.2 2.6.1 2.6.2 2.6.3 2.7.1" I suppose it makes sense to have this on hadoop-qa to catch
the fail before it gets committed. We can turn this down on other builds?

Yeah, I'd like to move most of these over to nightly and then just do i.e. 2.4.0, 2.5.0, 2.6.1,
and 2.7.1 in precommit.

This seems to be untrue now: "....even though we're not including that yet." regards zombie

I added that after I commented out all the "check for zombies" code. we're no longer examining
the process list for surefire after tests complete (though I suspect we're getting the same
checks for them out of log parsing now)

> Update test-patch to leverage Apache Yetus
> ------------------------------------------
>                 Key: HBASE-13525
>                 URL: https://issues.apache.org/jira/browse/HBASE-13525
>             Project: HBase
>          Issue Type: Improvement
>          Components: build
>            Reporter: Sean Busbey
>            Assignee: Sean Busbey
>              Labels: jenkins
>             Fix For: 2.0.0
>         Attachments: HBASE-13525.1.patch
> Once HADOOP-11746 lands over in Hadoop, incorporate its changes into our test-patch.
Most likely easiest approach is to start with the Hadoop version and add in the features we
have locally that they don't.

This message was sent by Atlassian JIRA

View raw message