Thanks, this sounds good to me. I’ll create a JIRA for this and get this
working.


On 2/2/16, 3:55 PM, "Kevin Minder" <[email protected]> wrote:

>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.
>>>>
>>>>
>>
>>

Reply via email to