[
https://issues.apache.org/jira/browse/BIGTOP-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283870#comment-14283870
]
jay vyas edited comment on BIGTOP-1608 at 1/20/15 3:26 PM:
-----------------------------------------------------------
1) Why run *from source* ?
Its a simple way to ensure that people using bigtop smoke tests :
- don't need to run {{mvn install}} or anything else ( i realize this can be
abstacted into yet another wrapper, but for my response to that, see (2) below)
.
- can modify Itest if they want, for some debugging/hacking and see results
easily w/o getting confused why their changes arent absorbed.
- *always* have the latest fixes. Last updates to itest (BIGTOP-1524) broke
the smoke-tests and made running latest itest a *requirement* for mapreduce
smoke tests.
So, where in test-artifacts, we say "install maven, then build these jars, then
you can run bigtop tests, oh and if you want to modify them - clean rebuild
everything, and start over" in smoke-tests we say "clone bigtop - then you can
run these tests. modifications? go for it. no change to your workflow.".
Which framework would you prefer as a user? For me, the latter :) !
2) Should we *wrap maven* ? We played with that idea in BIGTOP-1195. The
conclusion was : BEtter to build a easy to use framework with lower barrier to
entry, then just wrap a hard to use framework in a pretty UI. So ,
BIGTOP-1222 was born - a new framework which was so easy to use, and direct at
the same time - that *no wrappers at all were needed*...
Here are the benefits of the gradle smoke tests.
- Still have perfect JVM integration : We don't lose compilation against known
sources.
- don't need to scan 3 different directories
(test-framework,test-execution,test-artifacts) to determine the code path for
their tests. this is a complete show-stopper for anyone who is not a maven
guru.
- retain backward compatibliity w/ {{test-artifacts}} (i suggest we migrate
them into the new framework but wont start that debate here).
- run way faster, and way easier, literally, I think 10x faster last time i
checked. this means you can really rapidly test and run smoke-tests on a real
cluster and modify them while developing.
- no roadblocks to people who arent' maven/gradle experts. no hidden
dependencies.
- have some extra groovy tests? just drop em in a folder! they will run
automatically.
- inherit the easy to use gradle interface {{gradlew compileGroovy test
-Dsmoke.tests=pig}}
- will automatically run inside the bigtop auto-testing infrastructure which
runs on virtualbox *or* docker in the click of a button
Now, wrapping those w/ maven, we lose (3 or mabe 4) out of those benefits. The
original JIRA BIGTOP-1222, we decided that test-artifacts was only useful for
the purpose of freezing versoins of jars in binary test-artifacts. for all
other tests, smoke-tests approach works perfectly. So If we want to keep
{{test-artifacts}} *I promise to keep up the work* to make sure that
{{smoke-tests}} can use the source code from {{test-artifacts}} but i really
hope we dont take smoke-tests, which can run on any *java enabled linux machine
in 1 minute*, into something that had a bunch of dependencies, which took 8
minutes to run, and was impossible /error prone to modify at runtime. I ran
into that alot w/ maven - because I'd need to modify something in, say, a pig
test, then i'd need to clean the pig jar, and re run, hence all the work we put
into BIGTOP-1195 and BIGTOP-1222 to come to a cleaner decision. Any QE team
can easily adopt the current smoke-tests framework and add their own tests -
not at all the case w/ the maven style of jar based tests.
was (Author: jayunit100):
1) Why run *from source* ?
Its a simple way to ensure that people using bigtop smoke tests :
- don't need to run {{mvn install}} or anything else ( i realize this can be
abstacted into yet another wrapper, but for my response to that, see (2) below)
.
- can modify Itest if they want, for some debugging/hacking and see results
easily w/o getting confused why their changes arent absorbed.
- *always* have the latest fixes. Last updates to itest (BIGTOP-1524) broke
the smoke-tests and made running latest itest a *requirement* for mapreduce
smoke tests.
So, where in test-artifacts, we say "install maven, then build these jars, then
you can run bigtop tests, oh and if you want to modify them - clean rebuild
everything, and start over" in smoke-tests we say "clone bigtop - then you can
run these tests. modifications? go for it. no change to your workflow.".
Which framework would you prefer as a user? For me, the latter :) !
2) Should we *wrap maven* ? We played with that idea in BIGTOP-1195. The
conclusion was : BEtter to build a easy to use framework with lower barrier to
entry, then just wrap a hard to use framework in a pretty UI. So ,
BIGTOP-1222 was born - a new framework which was so easy to use, and direct at
the same time - that *no wrappers at all were needed*...
Here are the benefits of the gradle smoke tests.
- Still have perfect JVM integration : We don't lose compilation against known
sources.
- don't need to scan 3 different directories
(test-framework,test-execution,test-artifacts) to determine the code path for
their tests. this is a complete show-stopper for anyone who is not a maven
guru.
- run way faster, and way easier, literally, I think 10x faster last time i
checked. this means you can really rapidly test and run smoke-tests on a real
cluster and modify them while developing.
- no roadblocks to people who arent' maven/gradle experts. no hidden
dependencies.
- have some extra groovy tests? just drop em in a folder! they will run
automatically.
- inherit the easy to use gradle interface {{gradlew compileGroovy test
-Dsmoke.tests=pig}}
- will automatically run inside the bigtop auto-testing infrastructure which
runs on virtualbox *or* docker in the click of a button
Now, wrapping those w/ maven, we lose (3 or mabe 4) out of those benefits. The
original JIRA BIGTOP-1222, we decided that test-artifacts was only useful for
the purpose of freezing versoins of jars in binary test-artifacts. for all
other tests, smoke-tests approach works perfectly. So If we want to keep
{{test-artifacts}} *I promise to keep up the work* to make sure that
{{smoke-tests}} can use the source code from {{test-artifacts}} but i really
hope we dont take smoke-tests, which can run on any *java enabled linux machine
in 1 minute*, into something that had a bunch of dependencies, which took 8
minutes to run, and was impossible /error prone to modify at runtime. I ran
into that alot w/ maven - because I'd need to modify something in, say, a pig
test, then i'd need to clean the pig jar, and re run, hence all the work we put
into BIGTOP-1195 and BIGTOP-1222 to come to a cleaner decision. Any QE team
can easily adopt the current smoke-tests framework and add their own tests -
not at all the case w/ the maven style of jar based tests.
> all smoke-tests should compile and use iTest as source, no jar. Remove ITEST
> env variable.
> -------------------------------------------------------------------------------------------
>
> Key: BIGTOP-1608
> URL: https://issues.apache.org/jira/browse/BIGTOP-1608
> Project: Bigtop
> Issue Type: Improvement
> Components: tests
> Reporter: David Capwell
> Assignee: David Capwell
> Attachments: BIGTOP-1608-first-part.patch, BIGTOP-1608.1.patch
>
>
> If you try to run the smoke tests without setting {{BIGTOP_HOME}} they will
> run and be unable to find tests, so nothing runs. This variable should be
> added to checkEnv to make sure its present while running
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
