[
https://issues.apache.org/jira/browse/BIGTOP-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085216#comment-14085216
]
Konstantin Boudnik edited comment on BIGTOP-1222 at 8/4/14 8:19 PM:
--------------------------------------------------------------------
I applied the patch and ran {{gradle compileGroovy test -Dsmoke-tests=hive
--info}} and nothing happened: build just finished without doing anything. Is
it how it shall work?
A couple of other comments:
- shall new tasks be added to the default showHelp task? Or at lest be visible
via standard {{groovy tasks}} call?
- {{smoke-tests}} sysprop name: I believe more java'ish way of naming those'd
be like {{smokeTests}} or perhaps {{smock.tests}} (I personally prefer the
former as it is also more Maven like, but I am not married to it)
- it seems that some hive tests are exposed to the top-level build file of the
new module, i.e.
{code}
println("Now testing...");
test {
systemProperties['org.apache.bigtop.itest.hivesmoke.TestHiveSmokeBulk.test_include']
= 'basic'
testLogging {
events "passed", "skipped", "failed"
}
{code}
Is it intentional?
- do you have to specify both tasks {{compileGroovy test}} in the command line?
Can the latter simply depends on the former? Also, {{compileGroovy}} does sound
very broad: will it be used for _all_ groovy compilation down the road?
- looks like at least some of the new gradle files are missing ASL boiler-plate
Also, perhaps it makes sense to put the new smoke tests under {{bigtop-tests}}
to avoid creating top-level modules for everything?
was (Author: cos):
I applied the patch and ran {{gradle compileGroovy test -Dsmoke-tests=hive
--info}} and nothing happened: build just finished without doing anything. Is
it how it shall work?
A couple of other comments:
- shall new tasks be added to the default showHelp task? Or at lest be visible
via standard {{groovy tasks}} call?
- {{smoke-tests}} sysprop name: I believe more java'ish way of naming those'd
be like {{smokeTests}} or perhaps {{smock.tests}} (I personally prefer the
former as it is also more Maven like, but I am not married to it)
- it seems that some hive tests are exposed to the top-level build file of the
new module, i.e.
{code}
println("Now testing...");
test {
systemProperties['org.apache.bigtop.itest.hivesmoke.TestHiveSmokeBulk.test_include']
= 'basic'
testLogging {
events "passed", "skipped", "failed"
}
{code}
Is it intentional?
- do you have to specify both tasks {{compileGroovy test}} in the command line?
Can the latter simply depends on the former? Also, {{compileGroovy}} does sound
very broad: will it be used for _all_ groovy compilation down the road?
- looks like at least some of the new gradle files are missing ASL boiler-plate
> Simplify and gradleize a subset of the bigtop smokes
> ----------------------------------------------------
>
> Key: BIGTOP-1222
> URL: https://issues.apache.org/jira/browse/BIGTOP-1222
> Project: Bigtop
> Issue Type: Improvement
> Components: Build, Tests
> Affects Versions: 0.7.0
> Reporter: jay vyas
> Assignee: Konstantin Boudnik
> Fix For: backlog
>
> Attachments: BIGTOP-1222-2.patch, BIGTOP-1222.patch,
> BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch,
> BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch,
> BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch, BIGTOP-1222.patch
>
>
> (Rewritten the description for clarity)
> We need an easier way to run bigtop smoke tests, and gradle provides this:
> 1) Easy to script/modify
> 2) Human readable
> 3) equally oriented towards both groovy and plain old java
> The advantage of this method to running smokes :
> 1) No need to compile a jar : this is a costly step and not much value added,
> also creates indirection which can make debugging a broken test very hard.
> 2) Simple: A smoke test doesnt need to make low level API calls or be
> compiled against the right APIs - rather, it should test the end user
> interface ("hive -q ....", "pig -x ....", "hadoop jar ....", and so on).
> 3) Customizable: The smoke tests shouldnt require users to have to write XML
> and debug environmental variables / grep around for System properties etc.
> Rather, a high level controller should do all that checking for you.
> The initial idea was to write a python/bash implementation wrapper of
> scripts, but that was replaced by the idea of using gradle. The advantage of
> gradle is that we don't need to manually set the classpath and run groovy
> commands: Gradle wraps groovy scripts in their native java context quite
> nicely - but it doesnt add any other unnecessary overhead (xml, jar files, no
> need for complex xml tag wrappers for simple tasks - just plain groovy code).
> So, here the goal is just to create a nice, clean, extensible non-jar,
> non-API dependent gradle runner for the smoke tests which exersizes the
> hadoop cluster the same way a typical end-user would.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
