Subject: & specific gradle tasks

> On Feb 18, 2020, at 2:19 AM, Pierre Smits <[EMAIL PROTECTED]> wrote:
Great question, and now you're getting into where the precommit stuff really shines. :)

There are two possible ways to do this:

a) Build a new test

b) Modify an existing test (e.g., unit)

To do either of those  means digging into the API, but there are plenty of examples of how do either of these in the various personality files that ship with Yetus. But a quick rundown:

Option A:  Building a new test:

Precommit works by basically looking for functions that tell it what to do. Adding a new test is a matter of adding new plug-in functions and telling precommit about the prefix name of the functions that have been defined. has the list of function suffixes, what they do, variables that may be useful, and general information about how to write a plug-in.

For a simple test:
-  calling 'add_test_type <name>' to give the prefix.
- a filefilter function to help  determine when this test should activate (e.g., documentation vs. actual source)
- one or more step functions to actually do the work.  For an integration test, testname_rebuild is the way to go.

There are 3 or 4 of these in the hbase personality.

Option B: Change unit

For something like integrationTests, though, it may be better to just patch the unit test to be called with different parameters. This is a bit harder to understand, but is significantly less coding.  To do this, you'll need to create a personality_modules function in your personality file.  In this personality file, you'll basically control the flow of each test that precommit will trigger.  Because of this power, it also means you can change the parameters that are passed.

Quite a few of the personalities have one of these functions. Some are very complex (Hadoop) and some are relatively simple (most of them, including Pig and and Yetus). But they all share something in common:  they have some sort of "if test is foo" statement that does some particular overriding or adding to a particular test and then pushing the rest back into the build queue.

In this particular case, there would be a check if the test type is unit and if so, set what the gradlew command line parameters should be by calling personality_enqueue_module . (parameters).  [That . means root of the source tree.  Some build systems break the source up into different modules and precommit understands that and can short-cut full builds.  Alas, gradle doesn't do that so its work is always at the root of the tree.  Someday it'd be great to understand gradle's source sets so that precommit can shortcut builds for it too.]


Which one is better is a matter of expected outcome and preferences.  Given that unit tests and integrationists are generally independent, I'd probably lean towards building a new test.  But you'll need to probably experiment and look at what others have done to see which choice is the correct one for you.