arquillian
feat: Introduced additonal parallelism to the test suite execution
- the test-bed build uses Maven parallelism with 50 threads per cpu core
- the same is used for build invocation on Travis (could be used locally)
- the Travis is building in three virtual machines at once:
- one for unit tests
- one for functional tests - to separate unit tests and functional tests I had to introduce two profiles inside of the pom files
- one for generating documentation - no to do it in the previous builds/vm twice
- speeding up Java startup using properties: -XX:+TieredCompilation -XX:TieredStopAtLevel=1
Fixes #126
So the idea is to merge both PRs right? And thank you.
El 3 oct. 2017 5:02 p. m., "Matous Jobanek" [email protected] escribió:
- the test-bed build uses Maven parallelism with 50 threads per cpu core
- the same is used for build invocation on Travis (could be used locally)
- the Travis is building in three virtual machines at once:
- one for unit tests
- one for functional tests - to separate unit tests and functional tests I had to introduce two profiles inside of the pom files
- one for generating documentation - no to do it in the previous builds/vm twice
- speeding up Java startup using properties: -XX:+TieredCompilation -XX:TieredStopAtLevel=1
Fixes #126 https://github.com/arquillian/smart-testing/issues/126
You can view, comment on, or merge this pull request online at:
https://github.com/arquillian/smart-testing/pull/204 Commit Summary
- feat: Introduced additonal parallelism to the test suite execution
File Changes
- M .travis.yml https://github.com/arquillian/smart-testing/pull/204/files#diff-0 (21)
- M core/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-1 (16)
- M functional-tests/git-rules/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-2 (15)
- M functional-tests/test-bed/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-3 (16)
- M functional-tests/test-bed/src/main/java/org/arquillian/ smart/testing/ftest/testbed/project/BuildConfigurator.java https://github.com/arquillian/smart-testing/pull/204/files#diff-4 (12)
- M functional-tests/test-bed/src/main/java/org/arquillian/ smart/testing/ftest/testbed/project/ProjectBuilder.java https://github.com/arquillian/smart-testing/pull/204/files#diff-5 (1)
- M functional-tests/test-bed/src/test/java/org/arquillian/ smart/testing/ftest/configuration/SurefireForksConfigurationTest.java https://github.com/arquillian/smart-testing/pull/204/files#diff-6 (9)
- M junit-test-result-parser/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-7 (15)
- M mvn-extension/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-8 (16)
- M strategies/affected/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-9 (15)
- M strategies/changed/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-10 (15)
- M strategies/failed/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-11 (15)
- M surefire-provider/pom.xml https://github.com/arquillian/smart-testing/pull/204/files#diff-12 (16)
Patch Links:
- https://github.com/arquillian/smart-testing/pull/204.patch
- https://github.com/arquillian/smart-testing/pull/204.diff
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/arquillian/smart-testing/pull/204, or mute the thread https://github.com/notifications/unsubscribe-auth/ABcmYQtMStoQz0nySDeAV8bWKTtVLLzjks5sokxrgaJpZM4PsRCd .
yup - they are different solutions => separated PRs. Yours is important as well - to minimize the test suite
Yeah, I'm not a huge fan of profiles either so I completely understand your point/feeling. On the other hand, I would really welcome a simple way of executing only unit tests - just an example of the practical usage on the command line. In addition, there is no change of the usage - you can still use the original standard command of building/testing the whole project. Anyway, I'll rebase it with the latest changes, compare the time and if there is an improvement in the build time, then I'll add the explanation and finish the PR.
- [x] rebase
- [ ] compare the build time
- [ ] add documentation explanation
I would really welcome a simple way of executing only unit tests - just an example of the practical usage on the command line.
mvn test won't work here?
mvn test won't work here?
nope, that will execute the whole test suite
This brings an interesting question. How about removing the profiles and configure the failsafe plugin for functional tests? Then it would be possible to run only unit tests using mvn clean test, we could still have separated builds in Travis and we would get rid of the profiles...
The build times are pretty weird - in my Travis account, the build takes 15:41 but here on arquillian's 19:17 Similarly look also the Maven builds of the project: on my travis account 13:53 on Arquillian's account 17:26 The differences are quite huge and seem to be stable. Any idea what could be the cause? How about your accounts? Are they also faster? @bartoszmajsak @lordofthejars @hemanik @dipak-pawar
This brings an interesting question. How about removing the profiles and configure the failsafe plugin for functional tests? Then it would be possible to run only unit tests using mvn clean test, we could still have separated builds in Travis and we would get rid of the profiles...
That's exactly what was the bottom line of my short question :)
The build times are pretty weird
Could that be that there are other projects under arq organization which had running builds at the same time? Might be that we have resources constraints per organization on Travis.
I would simply measure against one of the places - preferably most isolated one - to compare before/after time.