This is hacky AF, but maybe we could reduce the contrib-check to the
PR changes on their submodules with something as simple ;) as
git diff --name-only HEAD^ | xargs -I{} dirname {} | uniq | xargs -I{}
ls {}/pom.xml 2>/dev/null | grep -v nifi-assembly | grep -v
"\./pom.xml" | grep -v "nifi-nar-bundles/pom.xml" | xargs -I{} mvn -f
{} install -Pcontrib-check
I think the grep -v's can be replaced with egrep -E or something,
and/or we could build a reactor project list for mvn -p, but basically
we find the changed submodules in the PR, ignore the top-level ones,
then run Maven (with contrib-check, etc.) on those submodules.
Ideally this would be a separate Travis "sub-build" like we do for
different JDKs, if something like that could be done.
Yeah time for bed, I'm either dreaming or delusional, or both :D
Regards,
Matt
P.S. I left the "clean" goal off the last guy in the chain, assuming
my bash-fu(?) would still allow for various submodules under a
submodule (like a -processors and -nar submodules) to be built, and
didn't want to wipe the environment. "This is just a test" :)
P.P.S. Seems like it's easier for the PR author to add a comment to
the PR saying they ran contrib-check, and a reviewer to run and
confirm or inquire (if such a comment was missing) :-P
On Fri, Jun 17, 2016 at 3:35 PM, Matt Gilman <[email protected]> wrote:
> Devs,
>
> The configuration for Travis CI has had the contrib-check profile turned
> off. Recent contributions that include additional unit tests have pushed
> the length of the build over Travis's allowed limit. We should be able to
> turn this back on as we more towards our extensions registry when we can
> decouple NiFi framework and extensions.
>
> In the meantime, any PR reviewers should run contrib-check locally instead
> of relying on the output from Travis.
>
> If anyone else knows of other options within Travis to allow us to keep
> this profile running, please let me know. Thanks!
>
> Matt
