Thanks for the summary, Busbey! I've been swamped at work and haven't had a chance to check out these options yet.
I will do so and let you know if not sufficient. Cheers, Karen On Aug 11, 2016 4:43 AM, "Sean Busbey" <[email protected]> wrote: > Hi Karen! > > Excellent question. Generally, to test changes to the precommit patch > tester I've seen folks make patches (using git format-patch) that have two > commits, one for their change and one that alters something related to what > they're changing. > > When such a patch shows up attached to a JIRA, precommit happily applies > both changes and then runs against them (incorporating most changes to test > patch itself in the process). > > If that won't work, then you can safely run test-patch on a local machine > against an arbitrary project checkout. With default options it shouldn't > reset the local source control working directory. So long as you don't give > it login credentials it won't post to JIRA, GitHub, etc. > > If you're trying to reproduce a particular project's use of precommit, then > one of the existing committers with access to builds.apache.org can get > you > the invocation details said project uses. > > Do either of those options help in this case? > On Aug 10, 2016 20:22, "Karen Clark" <[email protected]> wrote: > > > Howdy folks, > > > > I'm working on a trivial bug (YETUS-342) to update test-patch.sh to > > gracefully handle the situation where $BASEDIR does not exist. > > > > Now that I have a fix, I need to ensure I didn't break anything (and to > > ensure the fix works in various situations). > > > > Unfortunately, I'm not developing anything in the Hadoop ecosystem (or > > elsewhere!) that I can run my changes on to validate them using Yetus. > > > > Is there sample data available that we can test the code against without > > fear of committing anything? > > > > Thanks, > > Karen > > >
