[jira] [Created] (HADOOP-19385) S3A: add a file-format-parsing module for testing format parsing

Steve Loughran created HADOOP-19385: --- Summary: S3A: add a file-format-parsing module for testing format parsing Key: HADOOP-19385 URL: https://issues.apache.org/jira/browse/HADOOP-19385 Project

reminder: Hadoop 3.4.1 RC3 is up for testing and voting

Can as many people who have not yet tested and voted on the latest RC please put some time aside for this. We are short of a binding vote, and need as much testing in different deployments as possible -from everyone. Remember; this is your last chance to have any regressions you find to be fixed

Re: Recommended way of using hadoop-minicluster für unit testing?

; ab9b3f7ac8 > > > On Fri, 12 Apr 2024 at 10:41, Richard Zowalla > wrote: > > Hi, > > > > thanks for the fast reply. The PR is here [1]. > > > > It works, if I exclude the client-api and client-api-runtime from > > being scanned in surefire, which is a hack

Re: Recommended way of using hadoop-minicluster für unit testing?

gt; > thanks for the fast reply. The PR is here [1]. > > It works, if I exclude the client-api and client-api-runtime from being > scanned in surefire, which is a hacky workaround for the actual issue. > > The hadoop-commons jar is a transient dependency of the minicluster, which &

mozilla/public-suffix-list.txt and testing of hadoop-cos

t couldn't understand why given that both libraries were shaded. Now we know. Who is set up to test the hadoop-cos cloud connector? Because I've just changed its dependencies without doing the strict regression testing. And, as I am yet to kick off that 3.3.4 build but I want to get this

[jira] [Resolved] (HADOOP-14764) Über-jira adl:// Azure Data Lake Phase II: Performance, Resilience and Testing

formance, Resilience and Testing > -- > > Key: HADOOP-14764 > URL: https://issues.apache.org/jira/browse/HADOOP-14764 > Project: Hadoop Common >

[jira] [Resolved] (HADOOP-16832) S3Guard testing doc: Add required parameters for S3Guard testing in IDE

[ https://issues.apache.org/jira/browse/HADOOP-16832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Bota resolved HADOOP-16832. - Resolution: Fixed > S3Guard testing doc: Add required parameters for S3Guard testing in

[jira] [Created] (HADOOP-16832) Add required parameters to be set in testing doc for S3Gurad testing.

Mukund Thakur created HADOOP-16832: -- Summary: Add required parameters to be set in testing doc for S3Gurad testing. Key: HADOOP-16832 URL: https://issues.apache.org/jira/browse/HADOOP-16832 Project

[jira] [Created] (HADOOP-16583) Minor fixes to S3 testing instructions

Siddharth Seth created HADOOP-16583: --- Summary: Minor fixes to S3 testing instructions Key: HADOOP-16583 URL: https://issues.apache.org/jira/browse/HADOOP-16583 Project: Hadoop Common Issue

Re: [DISCUSS] Use of AssertJ for testing

Thank you for the discussion. I didn't know that assertj is already on the test classpath for some modules. > I think it'd be good to make the new tests Junit 5+ aspect, rather than > mixed, as it'll confuse backporting a lot. +1 for the idea. Here is a summary: - Let's upgrade the existing te

Re: [DISCUSS] Use of AssertJ for testing

+1, on AssertJ usage, thanks for getting this done. --Anu On 3/31/19, 9:37 PM, "Akira Ajisaka" wrote: Hi folks, Now I'm going to upgrade the JUnit version from 4 to 5 for Java 11 support. I wanted to start with the small module, so I uploaded a patch to upgrade the API in h

Re: [DISCUSS] Use of AssertJ for testing

assertj is already on the test classpath for some modules already, though an older version (3.8.0) from what's current (3.12.0) No problems seem to have surfaced, so I don't see anything wrong with picking it up more broadly. if someone wants to update the assertj version, it's only a test artifa

Re: [DISCUSS] Use of AssertJ for testing

> >> > + if any can point to some good articles/presentations on junit5+assertJ, > then please share the links > > >

Re: [DISCUSS] Use of AssertJ for testing

we are going to use AssertJ, when to use AssertJ (before > upgrading JUnit or after?) > > My opinion is: > - JUnit migration is required for Java 11, so upgrading JUnit as soon > as possible. > - After the migration, we may use AssertJ for existing tests. > - We may use AssertJ for n

Re: [DISCUSS] Use of AssertJ for testing

Thanks Akira. +1 for your opinion. I will review YARN-8943 after this discussion has finished. - Takanobu on 2019/04/01 14:07, "Sree V" wrote: My opinion: - Upgrade to JUnit5.- Use an Assertion Framework. Preferably, AssertJ as JUnit5 user guide full of it. Thank you./Sree

Re: [DISCUSS] Use of AssertJ for testing

My opinion: - Upgrade to JUnit5.- Use an Assertion Framework. Preferably, AssertJ as JUnit5 user guide full of it. Thank you./Sree On Sunday, March 31, 2019, 9:37:52 PM PDT, Akira Ajisaka wrote: Hi folks, Now I'm going to upgrade the JUnit version from 4 to 5 for Java 11 support. I

[DISCUSS] Use of AssertJ for testing

Hi folks, Now I'm going to upgrade the JUnit version from 4 to 5 for Java 11 support. I wanted to start with the small module, so I uploaded a patch to upgrade the API in hadoop-yarn-api module at first (YARN-8943), and in this JIRA, Szilard Nemeth suggested using AssertJ with JUnit 5. (Thanks Szi

[jira] [Created] (HADOOP-16065) -Ddynamodb should be -Ddynamo in AWS SDK testing document

Akira Ajisaka created HADOOP-16065: -- Summary: -Ddynamodb should be -Ddynamo in AWS SDK testing document Key: HADOOP-16065 URL: https://issues.apache.org/jira/browse/HADOOP-16065 Project: Hadoop

[jira] [Resolved] (HADOOP-9359) Add Windows build and unit test to test-patch pre-commit testing

and unit test to test-patch pre-commit testing > > > Key: HADOOP-9359 > URL: https://issues.apache.org/jira/browse/HADOOP-9359 > Project: Hadoop Common >

[jira] [Created] (HADOOP-15916) Testing: Trying workaround at SUREFIRE-1588

Akira Ajisaka created HADOOP-15916: -- Summary: Testing: Trying workaround at SUREFIRE-1588 Key: HADOOP-15916 URL: https://issues.apache.org/jira/browse/HADOOP-15916 Project: Hadoop Common

[jira] [Resolved] (HADOOP-7031) Make DelegateToFileSystem constructor public to allow implementations from other packages for testing

last 7 years so closing for now. > Make DelegateToFileSystem constructor public to allow implementations from > other packages for testing > - > > Key: HADOOP-7031 &

Dockerfile for testing HA clusters of yarn?

Folks, Are there any dockerfiles or the like for setting up a local HA cluster with yarn using Docker (or something other than multiple VMs), using a custom build of Hadoop (ideally, straight out of the build tree) ? Context: I’m working on changes for the ZKRMStateStore to alleviate a number

[jira] [Created] (HADOOP-15154) Abstract new method assertCapability for StreamCapabilities testing

Xiao Chen created HADOOP-15154: -- Summary: Abstract new method assertCapability for StreamCapabilities testing Key: HADOOP-15154 URL: https://issues.apache.org/jira/browse/HADOOP-15154 Project: Hadoop

[jira] [Resolved] (HADOOP-14552) Über-jira: WASB client phase II: performance and testing

: 2.9.0 3.0.0 Target Version/s: (was: 3.1.0) Moving everything in this list not in Hadoop 2.9/3.0 to HADOOP-15132; this JIRA now summarizes everything new w.r.t WASB integration. > Über-jira: WASB client phase II: performance and test

[jira] [Created] (HADOOP-14898) Create official Docker images for development and testing features

Elek, Marton created HADOOP-14898: - Summary: Create official Docker images for development and testing features Key: HADOOP-14898 URL: https://issues.apache.org/jira/browse/HADOOP-14898 Project

Patch testing on Windows [BETA]

I’m a little hesitant to share this because it’s really Not Quite Ready for primetime, but I figured others might want to play with it early anyway. https://builds.apache.org/view/H-L/view/Hadoop/job/Precommit-hadoop-win/ Will let you test patches on Wi

[jira] [Created] (HADOOP-14764) Über-jira adl:// Azure Data Lake Phase II: Performance and Testing

John Zhuge created HADOOP-14764: --- Summary: Über-jira adl:// Azure Data Lake Phase II: Performance and Testing Key: HADOOP-14764 URL: https://issues.apache.org/jira/browse/HADOOP-14764 Project: Hadoop

[jira] [Created] (HADOOP-14756) S3Guard: instrument MetadataStore for asserting & testing MetadataStoreTestBase

Steve Loughran created HADOOP-14756: --- Summary: S3Guard: instrument MetadataStore for asserting & testing MetadataStoreTestBase Key: HADOOP-14756 URL: https://issues.apache.org/jira/browse/HADOOP-1

Looking for reviewers after testing 3.0-alpha

Hi all, I was testing 3.0-alpha releases (build, install, run) and I found some bugs. Some of them were merged but some of them got stuck in "Patch Available" status. I am looking for reviewers for these tickets. I would be glad to see them in 3.0 HADOOP-14414. Calling maven-s

[jira] [Created] (HADOOP-14689) Dummy jira for testing barnch-2.7 build.

Konstantin Shvachko created HADOOP-14689: Summary: Dummy jira for testing barnch-2.7 build. Key: HADOOP-14689 URL: https://issues.apache.org/jira/browse/HADOOP-14689 Project: Hadoop Common

[jira] [Created] (HADOOP-14552) WASB client phase II: performance and testing

Steve Loughran created HADOOP-14552: --- Summary: WASB client phase II: performance and testing Key: HADOOP-14552 URL: https://issues.apache.org/jira/browse/HADOOP-14552 Project: Hadoop Common

[jira] [Created] (HADOOP-14532) TestOozieCLI.testSlaEvents is not testing SLAServlet.

Peter Cseh created HADOOP-14532: --- Summary: TestOozieCLI.testSlaEvents is not testing SLAServlet. Key: HADOOP-14532 URL: https://issues.apache.org/jira/browse/HADOOP-14532 Project: Hadoop Common

[jira] [Resolved] (HADOOP-14532) TestOozieCLI.testSlaEvents is not testing SLAServlet.

[ https://issues.apache.org/jira/browse/HADOOP-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Cseh resolved HADOOP-14532. - Resolution: Invalid > TestOozieCLI.testSlaEvents is not testing SLAServ

[jira] [Created] (HADOOP-14099) Split s3 testing section out into its own file

Steve Loughran created HADOOP-14099: --- Summary: Split s3 testing section out into its own file Key: HADOOP-14099 URL: https://issues.apache.org/jira/browse/HADOOP-14099 Project: Hadoop Common

[jira] [Created] (HADOOP-13758) HADOOP-13614 pre-commit testing JIRA

Chris Nauroth created HADOOP-13758: -- Summary: HADOOP-13614 pre-commit testing JIRA Key: HADOOP-13758 URL: https://issues.apache.org/jira/browse/HADOOP-13758 Project: Hadoop Common Issue

[jira] [Resolved] (HADOOP-7678) Nightly build+test should run with "continue on error" for automated testing after successful build

ild+test should run with "continue on error" for automated testing > after successful build > --- > > Key: HADOOP-7678 > URL: https://issues.apache

Testing Hadoop based system with large sets of data

Hi How do i test ingestion speed of my system? i want to test with particular types of data Are there any tools, which generate this type of data? Thanks in advance Basavaraj - To unsubscribe, e-mail: common-dev-unsubscr...@ha

Re: is jenkins testing PRs?

Once you log in, you can specify the YARN JIRA number using: https://builds.apache.org/job/PreCommit-yarn-Build/build?delay=0sec FYI On Mon, Jan 11, 2016 at 9:01 AM, Steve Loughran wrote: > > I submitted some PR-based patches last week —they haven't been tested yet > > https://issues.apache.or

is jenkins testing PRs?

I submitted some PR-based patches last week —they haven't been tested yet https://issues.apache.org/jira/browse/YARN-4567 Is there a way for someone like me with Jenkins admin rights to kick this off?

Re: setting up a local ubuntu VM for building and testing hadoop

I tried that already, and in my case it doesn't seem to fix the problem. For example (my short hostname is "udesktop"), Running org.apache.hadoop.yarn.server.resourcemanager.TestAMAuthorization Tests run: 4, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 11.936 sec <<< FAILURE! - in org.apache.

Re: setting up a local ubuntu VM for building and testing hadoop

Hello Sangjin I had similar problems recently.. Got around it by modifying my /etc/hosts. I just update the 127.0.0.1 entry to add the short hostname of the machine like so : ... 127.0.0.1 localhost ... On Wed, Jan 6, 2016 at 8:52 AM, Sangjin Lee wrote: > Has anyone set up an ubuntu VM to buil

setting up a local ubuntu VM for building and testing hadoop

Has anyone set up an ubuntu VM to build hadoop and run unit tests locally? I'm familiar with setting up a linux machine to build and test hadoop, but a VM (I'm using Parallels on mac) seems to cause issues regarding resolving the localhost address. I get all kinds of UnknownHostExceptions and varia

[GitHub] hadoop pull request: HADOOP-11919 Testing Github integration

Github user asfgit closed the pull request at: https://github.com/apache/hadoop/pull/40 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabl

Re: [GitHub] hadoop pull request: HADOOP-11919 Testing Github integration

Responding to a comment on github. On Fri, Oct 30, 2015 at 10:11 AM, omalley wrote: > Github user omalley commented on the pull request: > > https://github.com/apache/hadoop/pull/40#issuecomment-152589471 > > Testing comments on github pull requests. > > > ---

[GitHub] hadoop pull request: HADOOP-11919 Testing Github integration

GitHub user omalley opened a pull request: https://github.com/apache/hadoop/pull/40 HADOOP-11919 Testing Github integration This is a test. You can merge this pull request into a Git repository by running: $ git pull https://github.com/omalley/hadoop hadoop-11919

[GitHub] hadoop pull request: HADOOP-11919 Testing Github integration

Github user omalley commented on the pull request: https://github.com/apache/hadoop/pull/40#issuecomment-152589471 Testing comments on github pull requests. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project

[jira] [Reopened] (HADOOP-11880) aw jira sub-task testing, ignore

[ https://issues.apache.org/jira/browse/HADOOP-11880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer reopened HADOOP-11880: --- > aw jira sub-task testing, ign

[jira] [Resolved] (HADOOP-11880) aw jira sub-task testing, ignore

[ https://issues.apache.org/jira/browse/HADOOP-11880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HADOOP-11880. --- Resolution: Fixed > aw jira sub-task testing, ign

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

set of build tools that are customizable to fit the norms of >>> different software communities is a bunch of work. Making it work well in >>> both the context of automated test systems like Jenkins and for individual >>> developers is even more work. We could easily also

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

f work. Making it work well in >> both the context of automated test systems like Jenkins and for individual >> developers is even more work. We could easily also take over maintenance of >> things like shelldocs, since test-patch is the primary consumer of that >> currently

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

;> >>>>> Longer term: >>>>> >>>>>* I’ve been toying with the idea of (ab)using Java repos and >>>>> packaging as a transportation layer, either in addition or in >>> combination >>>>> with something like

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

; > think we'd be fine having folks work off of the corresponding tag. I'm > > not > > > sure there's much reason to do that, however. A Jenkins job can just as > > > easily grab a release tarball as a git tag and we're not talking about > a > > > l

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

can't package things > > up as a tool, similar to how findbugs or shellcheck work. We can make OS > > packages (or homebrew for OS X) if we want to make stand alone > installation > > on developer machines real easy. Those same packages could be installed > on > >

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

e packages could be installed on > the ASF build machines, provided some ASF project wanted to make use of > Yetus. > > Having releases will incur some turn around time for when folks want to see > fixes, but that's a trade off around release cadence we can work out longer > t

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

est-patch, I think the proposed project has some future > growth potential. Given some adoption of test-patch to prove utility, the > project could build on the ties it makes to start building tools to help > projects do their own longer-run testing. Note that I'm talking about the >

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

For words beginning with "Y" Yale: Mythical animal elephant/boar. After some quick Googling, it's apparently originally documented by "Pliny the Elder", so it's got a beer-related connotation too. Downside, might get confused with the university of the same name. Yare: adj for quick/agile/lively

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

> On 17 Jun 2015, at 03:55, Sean Busbey wrote: > > The name is, of course, up to the proposed PMC. As a bit of background, the > current name Yetus fulfills Allen's desire to have something shell related > and my desire to have a project that starts with Y (there are currently no > ASF projects

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

erm. I would like to have one or two projects that can work off of the bleeding edge repo, but we'd have to get that to mesh with foundation policy. My gut tells me we should be able to come up with an agreement that makes such a project "part of the development community" but the speci

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

I think it's good to have a general build/test process projects can share, so +1 to pulling it out. You should get help from others. regarding incubation, it is a lot of work, especially for something that's more of an in-house tool than an artifact to release and redistribute. You can't just

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

Since a couple of people have brought it up: I think the release question is probably one of the big question marks. Other than tar balls, how does something like this actually get used downstream? For test-patch, in particular, I have a few thoughts on this: Short term:

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

could easily also take over maintenance of > things like shelldocs, since test-patch is the primary consumer of that > currently but it's generally useful tooling. > > In addition to test-patch, I think the proposed project has some future > growth potential. Given some adopt

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

has some future > growth potential. Given some adoption of test-patch to prove utility, the > project could build on the ties it makes to start building tools to help > projects do their own longer-run testing. Note that I'm talking about the > tools to build QA processes and not

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

ake over maintenance > of > > things like shelldocs, since test-patch is the primary consumer of that > > currently but it's generally useful tooling. > > > > In addition to test-patch, I think the proposed project has some future > > growth poten

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

tooling. > > In addition to test-patch, I think the proposed project has some future > growth potential. Given some adoption of test-patch to prove utility, the > project could build on the ties it makes to start building tools to help > projects do their own longer-run testing. Note

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

;>> out of all those in the various projects) and it's reached a point >>>>where >>> we >>>> think we can start bringing on other downstream users. This means we >>>>need >>>> to start establishing things like a release cadence and

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

it's generally useful tooling. In addition to test-patch, I think the proposed project has some future growth potential. Given some adoption of test-patch to prove utility, the project could build on the ties it makes to start building tools to help projects do their own longer-run testing. N

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

> both the context of automated test systems like Jenkins and for > individual > > developers is even more work. We could easily also take over maintenance > of > > things like shelldocs, since test-patch is the primary consumer of that > > currently but it's generally usefu

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

ake over maintenance of > things like shelldocs, since test-patch is the primary consumer of that > currently but it's generally useful tooling. > > In addition to test-patch, I think the proposed project has some future > growth potential. Given some adoption of test-patc

Re: [DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

tch to prove utility, the project could build on the ties it makes to start building tools to help projects do their own longer-run testing. Note that I'm talking about the tools to build QA processes and not a particular set of tested components. Specifically, I think the ChaosMonkey work

[DISCUSS] project for pre-commit patch testing (was Re: upstream jenkins build broken?)

just look in the dev-support folder in the >>> HBase >>> repo? Is there any additional context we need to be aware of? >>> >>> Chris Nauroth >>> Hortonworks >>> http://hortonworks.com/ >>> >>> >>> >>>

RE: IMPORTANT: testing patches for branches

-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org Subject: Re: IMPORTANT: testing patches for branches On Apr 22, 2015, at 11:34 PM, Zheng, Kai wrote: > Hi Allen, > > This sounds great. > >>> Naming a patch foo-HDFS-7285.00.patch should get te

[jira] [Created] (HADOOP-11880) aw jira sub-task testing, ignore

Allen Wittenauer created HADOOP-11880: - Summary: aw jira sub-task testing, ignore Key: HADOOP-11880 URL: https://issues.apache.org/jira/browse/HADOOP-11880 Project: Hadoop Common Issue

Re: IMPORTANT: testing patches for branches

Allen, I am not questioning whether checkstyle is a requirement. My concern is that some of the rules in there are arcane/unnecessary - we should use a better list of rules, in my opinion. This is why I filed HADOOP-11869. As pointed out by Jason, this is not a dupe of HADOOP-11866

Re: IMPORTANT: testing patches for branches

On Apr 23, 2015, at 7:57 PM, Sidharta Seethana wrote: > About (3.) , a lot of the check style rules seem to be arcane/unnecessary. > Please see : https://issues.apache.org/jira/browse/HADOOP-11869 a) I've closed it as a dupe of HADOOP-11866 to keep everything in one place. b) I've had HADO

Re: IMPORTANT: testing patches for branches

On Apr 24, 2015, at 3:09 AM, Brahma Reddy Battula wrote: > The patch artifact directory on has been removed! > This is a fatal error for test-patch.sh. Aborting. > Jenkins (node H8) information at > https://builds.apache.org/job/PreCommit-YARN-Build/7477/ may provide some > hints. ( did I mi

RE: IMPORTANT: testing patches for branches

hana [sidharta.apa...@gmail.com] Sent: Friday, April 24, 2015 12:27 AM To: common-dev@hadoop.apache.org Subject: Re: IMPORTANT: testing patches for branches About (3.) , a lot of the check style rules seem to be arcane/unnecessary. Please see : https://issues.apache.org/jira/browse/HADOOP-11869 On Thu, Ap

Re: IMPORTANT: testing patches for branches

About (3.) , a lot of the check style rules seem to be arcane/unnecessary. Please see : https://issues.apache.org/jira/browse/HADOOP-11869 On Thu, Apr 23, 2015 at 10:45 AM, Steve Loughran wrote: > > 1. I really like the new patch process, especially the at-a-glance summary > 2. I think being -1

Re: IMPORTANT: testing patches for branches

1. I really like the new patch process, especially the at-a-glance summary 2. I think being -1 on whitespace is overkill; Its just part of my " git apply -p 0 -3 --verbose --whitespace=fix " action. Accordingly, I won't reject patches on whitespace alone. 3. if checkstyle is complaining, how to

Re: IMPORTANT: testing patches for branches

On Apr 22, 2015, at 11:34 PM, Zheng, Kai wrote: > Hi Allen, > > This sounds great. > >>> Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285 >>> branch. > Does it happen locally in developer's machine when running test-patch.sh, or > also mean something in Hadoop Jen

RE: IMPORTANT: testing patches for branches

available? Thanks. Regards, Kai -Original Message- From: Allen Wittenauer [mailto:a...@altiscale.com] Sent: Thursday, April 23, 2015 3:35 AM To: common-dev@hadoop.apache.org Cc: yarn-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org; hdfs-...@hadoop.apache.org Subject: IMPORTANT: te

Re: IMPORTANT: testing patches for branches

; as well. :) (with kudos to OOM for the idea.) > > On Apr 22, 2015, at 8:57 PM, Allen Wittenauer wrote: > > > > > More than likely. It probably needs more testing (esp under Jenkins). > > > > It should be noted that the code in test-patch.sh has lots of problems

Re: IMPORTANT: testing patches for branches

Oh, this is also in the release notes, but one can use a git reference # as well. :) (with kudos to OOM for the idea.) On Apr 22, 2015, at 8:57 PM, Allen Wittenauer wrote: > > More than likely. It probably needs more testing (esp under Jenkins). > > It should be noted that

Re: IMPORTANT: testing patches for branches

More than likely. It probably needs more testing (esp under Jenkins). It should be noted that the code in test-patch.sh has lots of problems with branch-0, minor, and micro releases. But for major releases, it seems to work well for me. :) On Apr 22, 2015, at 8:45 PM, Vinod Kumar

Re: IMPORTANT: testing patches for branches

if you name the patch with the branch name > following the spec in HowToContribute (and a few other ways… test-patch tries > to figure it out!), test-patch.sh *should* be switching the repo over to that > branch for testing. > > For example, naming a patch foo-branch-2

IMPORTANT: testing patches for branches

* be switching the repo over to that branch for testing. For example, naming a patch foo-branch-2.01.patch should get tested on branch-2. Naming a patch foo-HDFS-7285.00.patch should get tested on the HDFS-7285 branch. This hopefully means that there should really be no more

[jira] [Created] (HADOOP-11820) aw jira testing, ignore

Allen Wittenauer created HADOOP-11820: - Summary: aw jira testing, ignore Key: HADOOP-11820 URL: https://issues.apache.org/jira/browse/HADOOP-11820 Project: Hadoop Common Issue Type: Task

[jira] [Created] (HADOOP-11440) Use "test.build.dir" instead of "build.test.dir" for testing in ClientBaseWithFixes

Akira AJISAKA created HADOOP-11440: -- Summary: Use "test.build.dir" instead of "build.test.dir" for testing in ClientBaseWithFixes Key: HADOOP-11440 URL: https://issues.apache.org/jira

[jira] [Resolved] (HADOOP-9540) Expose the InMemoryS3 and S3N FilesystemStores implementations for Unit testing.

) 2.6.0 Assignee: Steve Loughran > Expose the InMemoryS3 and S3N FilesystemStores implementations for Unit > testing. > > > Key: HADOOP-9540 > URL: https://issu

[jira] [Reopened] (HADOOP-9540) Expose the InMemoryS3 and S3N FilesystemStores implementations for Unit testing.

[ https://issues.apache.org/jira/browse/HADOOP-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang reopened HADOOP-9540: --- > Expose the InMemoryS3 and S3N FilesystemStores implementations for Unit > t

[jira] [Created] (HADOOP-11070) Create MiniKMS for testing

Alejandro Abdelnur created HADOOP-11070: --- Summary: Create MiniKMS for testing Key: HADOOP-11070 URL: https://issues.apache.org/jira/browse/HADOOP-11070 Project: Hadoop Common Issue

[jira] [Resolved] (HADOOP-6197) Use aspects to introduce new methods required for testing

red for testing > - > > Key: HADOOP-6197 > URL: https://issues.apache.org/jira/browse/HADOOP-6197 > Project: Hadoop Common > Issue Type: Test > Components: sec

[jira] [Resolved] (HADOOP-5916) Standardize fall-back value of test.build.data for testing directories

all-back value of test.build.data for testing directories > -- > > Key: HADOOP-5916 > URL: https://issues.apache.org/jira/browse/HADOOP-5916 > Project: Hadoop Common >

Re: unit testing and execution guide

Thanks steve. Will check them out. From: Steve Loughran To: "common-dev@hadoop.apache.org" ; Hai Huang Cc: "yuzhih...@gmail.com" Sent: Monday, September 16, 2013 5:18:14 AM Subject: Re: unit testing and execution guide Have a look at https://wiki.apache.org/hadoop/H

Re: unit testing and execution guide

Have a look at https://wiki.apache.org/hadoop/HowToDevelopUnitTests , which (now) explains the miniclusters​ -which you can use for testing against in-VM HDFS and YARN cluster simulations. Passing unit tests doesn't mean your code works in a real cluster, but failing them does mean that it

Re: unit testing and execution guide

From: Ted Yu To: common-dev@hadoop.apache.org; Hai Huang Sent: Saturday, September 14, 2013 2:54:13 PM Subject: Re: unit testing and execution guide Have you read 'Making Changes' section in http://wiki.apache.org/hadoop/HowToContribute? On Fri, Sep 13, 2013 at 9:26 PM,

Re: unit testing and execution guide

Have you read 'Making Changes' section in http://wiki.apache.org/hadoop/HowToContribute ? On Fri, Sep 13, 2013 at 9:26 PM, Hai Huang wrote: > Hi All, > > Are there latest instructions of unit testing and how to run hadoop in > somewhere? Although there are some unit t

RE: unit testing and execution guide

Hi All,   Are there latest instructions of unit testing and how to run hadoop in somewhere?  Although  there are some unit testing and  hadoop run documents in the wiki page. But it seems that there are out-of-date. I just downloaded hadoop by git couple of days ago. I was able to build it

[jira] [Created] (HADOOP-9925) Remove testing related codes out of UGI class

Kai Zheng created HADOOP-9925: - Summary: Remove testing related codes out of UGI class Key: HADOOP-9925 URL: https://issues.apache.org/jira/browse/HADOOP-9925 Project: Hadoop Common Issue Type

[jira] [Created] (HADOOP-9848) Create a MiniKDC for use with security testing

Wei Yan created HADOOP-9848: --- Summary: Create a MiniKDC for use with security testing Key: HADOOP-9848 URL: https://issues.apache.org/jira/browse/HADOOP-9848 Project: Hadoop Common Issue Type: New

[jira] [Created] (HADOOP-9540) Expose the InMemoryS3 and S3N FilesystemStores implementations for Unit testing.

Hariprasad Kuppuswamy created HADOOP-9540: - Summary: Expose the InMemoryS3 and S3N FilesystemStores implementations for Unit testing. Key: HADOOP-9540 URL: https://issues.apache.org/jira/browse/HADOOP

  1   2   >