Thanks Matt! Having contrib-check in travis has been a really valuable tool so thanks for putting that back in play.
On Thu, Jun 23, 2016 at 2:19 PM, Matt Gilman <[email protected]> wrote: > Devs, > > After adding more access control tests as part of the authorization work > for 1.0.0, the length of the Travis build exceeded the allowed limit even > without the contrib-check profile. So, I have migrated those tests to > integration tests and re-enabled the contrib-check profile in Travis. > > These tests launch an embedded Jetty instance and verify the access > controls are correct for the REST API. I would have liked to have left them > running as part of the default build but Travis was really struggling with > them. Anyways, they can be enabled manually with the 'integration-tests' > profile. > > Matt > > On Fri, Jun 17, 2016 at 10:10 PM, Matt Burgess <[email protected]> wrote: > >> 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 >>
