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

{code}
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
```bash
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
```bash
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.
{code}

{quote}
I see this in personality:
+ PATCH_BRANCH_DEFAULT=master
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?
{quote}

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/

{quote}
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?
{quote}

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.

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

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
(v6.3.4#6332)

Mime
View raw message