Hey Larry, I can understand the concern. To answer your question, ³ant package² will run all the tests right now since the ReleaseTests are tied to the release profile. If we do not want this behavior then we can either change ant package or probably more likely add another profile for the tests, something like Œrelease-tests¹ (?).
If we add a new profile we just need to change jenkins to do something like: mvn -Prelease,release-tests clean install On 1/22/16, 11:15 AM, "larry mccay" <[email protected]> wrote: >Hi Sumit - > >This is great news! > >One thing that I want to be clear about... > >I use "ant package" pretty exclusively during development and testing. >Which I use in conjunction with "ant install-test-home, >start-test|debug-gateway" and have published a couple articles/blogs that >prescribe this as part of the development process. > >1. what is the behavior of this ant target given these changes? >2. I think that it shouldn't include the release tests > >I would also like to see there be minimum patch submit criteria of the >equivalent to "mvn clean install" and commit to require a auto-triggered >precommit build that possibly includes the release tests. We need to get >that precommit trigger working. > >Depending on how much time the release tests are going to add, this may >give us the best coverage prior to commit. > >I could also be convinced that the release tests only be run after commit >and errors addressed as they fail. > >thanks, > >--larry > > >On Fri, Jan 22, 2016 at 10:48 AM, Sumit Gupta ><[email protected]> >wrote: > >> Hey everyone, >> >> Besides a review of the test case itself in KNOX-651, I wanted to >> review/discuss the changes made to the test annotations and the maven >>build >> lifecycle for the project. >> >> As we had discussed on a separate thread, we wanted to bring in some >> integration tests involving the various services with Kerberos enabled. >>The >> first attempt made in this work item is with WebHDFS using the mini KDC >>in >> hadoop common. >> >> The other goal we had in mind is to run the integration tests on Jenkins >> and not necessarily run them all the time during development (although >>you >> should be able to if you wanted to). To allow for this, two annotations >> have been added (actually the existing annotations of FunctionalTests >>and >> IntegrationTests have been renamed). >> >> - VerifyTest: These are essentially functional tests and will run if you >> execute 'mvn verify' or 'mvn install' >> - ReleaseTest: These are integration tests that help us verify the build >> and are not necessarily tests you want to run during development. These >>run >> by enabling the 'release' profile I.e. executing 'mvn -Prelease install' >> >> Both VerifyTest and ReleaseTest have been bound to the >>'integration-test' >> phase in the maven lifecycle, but ReleaseTests are only added and run if >> the release profile is enabled. So what this also means is that you can >>now >> run only plain old unit tests with 'mvn test' for a quick sanity check >> during development. >> >> So how does this affect the ant commands? Right now the ant commands are >> the way they used to be, in that 'ant verify' always ran everything and >>it >> is still does (everything now being Unit, VerifyTest and ReleaseTests). >> This can of course be a bit confusing as it does not match the 'mvn >>verify' >> command. This also begs the question on what should the commit criteria >>be? >> Doing a 'mvn clean install' should be sufficient in my mind but if you >>are >> used to using the ant commands, we may need new ones and/or need to >>modify >> existing ones. >> >> Thoughts? >> >> Sumit. >> >>
