> On Sep 5, 2016, at 2:13 AM, Ajay Yadava <[email protected]> wrote:
>
> I am evaluating Yetus for configuring precommit checks on Apache Falcon. My
> requirement is very simple, take a patch, apply it and run 'mvn clean
> install -Ptest-patch'. We use this profile to run tests, checkstyle,
> findbugs and rat checks.
precommit wasn't really built with the idea of 'one profile to rule
them all'. It's going to want to run each test separately so that it can do
timings, allow for features to be enabled/disabled as necessary, separate out
exactly which steps failed, etc. It does do what it can to avoid
recompilation, however, by avoiding cleans as much as it can. It was really
designed with fine grained information as part of it's basic architecture.
> Also, we want tests to be run for all modules and
> not just for modules with changes.
A custom personality_modules is exactly how to do that. There are
projects that do that (Accumulo comes to mind), but you lose a lot of
advantages that precommit can give you. Running per-module allows precommit to
give much more fine grained error information as well as avoiding the "skip the
rest of the build" issue that can cause contributors to submit many more
patches than they would otherwise. Remember also that you can also design your
personality_modules such that compiles, etc, happen at the module level but
unit tests run at the top level.
> This activates the profile, but it seems that on mvninstall the code at [1]
> always disables tests, checkstyle etc. and I am not able to find a hook /
> example to get the desired result. Is there a way to achieve the desired
> result using builtin plugins or do I need to write a new plugin?
If you *really really really* want one profile to rule them all, then
yes, you'll likely need to write a new plug-in that calls all of the other
plug-ins or includes all of the other plug-ins code.
> Also, is
> it possible to run mvninstall only after patch has been applied
> ('repostatus' == 'patch')?
You can always put a nop in personality_modules. But really you
probably shouldn't do that. Mainly because that initial install is great for
getting the maven repo down to a common base before applying the patch. If
there are problems, users know that the source tree itself was broken and it
wasn't caused by the patch. With only one mvn install, some effort will have to
be spent investigating. The second maven install goes *extremely* fast if
modules are enabled...
