I was thinking we could take this opportunity to clean up and align some of the ant/mvn workflows.
The resulting could be something like this: * ant verify == mvn clean verify ** This would compile, run unit and surefire based functional tests. * ant package == mvn -Ppackage clean install ** This would compile, run unit and surefire based functional tests and create binary packages ** This could be followed by 'ant install-test-home' or combined 'ant package install-test-home' ** IMPORTANT: This would be the gating criteria for a commit * ant release == man -Ppackage,release clean install ** This would compile, run all tests (including failsafe based integration tests) and create binary package. ** This would be the job run on the Jenkins servers. Thoughts? The only significant change in the above is that -Prelease is split into two profiles. -Ppackage which causes the packaging of the binaries. -Prelease which causes the execution of the failsafe based integration tests. On 1/22/16, 11:30 AM, "Sumit Gupta" <[email protected]> wrote: >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. >>> >>> > >
