OpenSearch/qa/sql/build.gradle

176 lines
6.1 KiB
Groovy
Raw Normal View History

import org.elasticsearch.gradle.precommit.PrecommitTasks
import org.elasticsearch.gradle.test.RunTask
description = 'Integration tests for SQL'
apply plugin: 'elasticsearch.build'
dependencies {
compile "org.elasticsearch.test:framework:${versions.elasticsearch}"
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
// JDBC testing dependencies
if (false == isEclipse && false == isIdea) {
// If we're not doing IDE stuff use the shadowed jar
compile(project(path: ':x-pack-elasticsearch:sql:jdbc', configuration: 'shadow'))
} else {
/* If we're doing IDE stuff then use then use the project
* dependency so the IDEs don't get confused. Transitive
* deps are OK here too because this is the only time we
* pull all of those deps in. We make sure exclude them
* below so they don't cause jar hell with the shadowed
* jar. */
compile(project(':x-pack-elasticsearch:sql:jdbc'))
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
}
compile "net.sourceforge.csvjdbc:csvjdbc:1.0.34"
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
runtime "com.h2database:h2:1.4.194"
// used for running debug tests
runtime 'org.antlr:antlr4-runtime:4.5.3'
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
// There are *no* CLI testing dependencies because we
// communicate fork a new CLI process when we need it.
// Used to support embedded testing mode
compile(project(':x-pack-elasticsearch:sql:server')) {
transitive = false
}
compile(project(':x-pack-elasticsearch:sql:cli-proto')) {
transitive = false
}
compile "org.elasticsearch.client:transport:${version}"
}
/* disable unit tests because these are all integration tests used
* other qa projects. */
test.enabled = false
dependencyLicenses.enabled = false
// Allow for com.sun.net.httpserver.* usage for embedded mode
eclipse {
classpath.file {
whenMerged { cp ->
def con = entries.find { e ->
e.kind == "con" && e.toString().contains("org.eclipse.jdt.launching.JRE_CONTAINER")
}
con.accessRules.add(new org.gradle.plugins.ide.eclipse.model.AccessRule(
"accessible", "com/sun/net/httpserver/*"))
}
}
}
forbiddenApisMain {
bundledSignatures -= 'jdk-non-portable'
bundledSignatures += 'jdk-internal'
}
// the main files are actually test files, so use the appropriate forbidden api sigs
forbiddenApisMain {
signaturesURLs = [PrecommitTasks.getResource('/forbidden/es-all-signatures.txt'),
PrecommitTasks.getResource('/forbidden/es-test-signatures.txt')]
}
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
thirdPartyAudit.excludes = [
// H2 dependencies that we don't actually use....
'javax.servlet.ServletConfig',
'javax.servlet.ServletContext',
'javax.servlet.ServletContextEvent',
'javax.servlet.ServletContextListener',
'javax.servlet.ServletOutputStream',
'javax.servlet.http.HttpServlet',
'javax.servlet.http.HttpServletRequest',
'javax.servlet.http.HttpServletResponse',
'org.apache.lucene.document.Field$Index',
'org.apache.lucene.queryParser.QueryParser',
'org.osgi.framework.BundleActivator',
'org.osgi.framework.BundleContext',
'org.osgi.service.jdbc.DataSourceFactory',
'org.slf4j.Logger',
'org.slf4j.LoggerFactory',
]
subprojects {
apply plugin: 'elasticsearch.standalone-rest-test'
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
configurations {
cliFixture
}
dependencies {
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
/* Since we're a standalone rest test we actually get transitive
* dependencies but we don't really want them because they cause
* all kinds of trouble with the jar hell checks. So we suppress
* them explicitly for non-es projects. */
testCompile(project(':x-pack-elasticsearch:qa:sql')) {
transitive = false
}
testCompile "org.elasticsearch.test:framework:${versions.elasticsearch}"
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
// JDBC testing dependencies
testRuntime(project(':x-pack-elasticsearch:sql:jdbc')) {
if (false == isEclipse && false == isIdea) {
/* Skip the transitive dependencies of the server when outside
* of an IDE because outside of an IDE we use the jdbc jar
* which includes all the transitive dependencies *already*.
* If we didn't skip these dependencies the jar hell checks
* would fail. And we need the transitive dependencies to
* run in embedded mode but only do that inside of an IDE. */
transitive = false
}
}
testRuntime("net.sourceforge.csvjdbc:csvjdbc:1.0.34") {
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
transitive = false
}
testRuntime("com.h2database:h2:1.4.194") {
transitive = false
}
testRuntime("org.antlr:antlr4-runtime:4.5.3") {
transitive = false
}
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
cliFixture project(':x-pack-elasticsearch:test:sql-cli-fixture')
// Used to support embedded testing mode
testRuntime(project(':x-pack-elasticsearch:sql:server')) {
transitive = false
}
testRuntime "org.elasticsearch.client:transport:${version}"
}
if (project.name != 'security') {
// The security project just configures it subprojects
apply plugin: 'elasticsearch.rest-test'
task cliFixture(type: org.elasticsearch.gradle.test.AntFixture) {
Project cli = project(':x-pack-elasticsearch:sql:cli')
dependsOn project.configurations.cliFixture
dependsOn cli.jar
executable = new File(project.javaHome, 'bin/java')
env 'CLASSPATH', "${ -> project.configurations.cliFixture.asPath }"
args 'org.elasticsearch.xpack.sql.cli.fixture.CliFixture',
baseDir, "${ -> cli.jar.outputs.files.singleFile}"
}
integTestCluster {
distribution = 'zip'
plugin project(':x-pack-elasticsearch:plugin').path
setting 'xpack.monitoring.enabled', 'false'
setting 'xpack.ml.enabled', 'false'
setting 'xpack.watcher.enabled', 'false'
setting 'script.max_compilations_rate', '1000/1m'
dependsOn cliFixture
}
Move all sql integration tests into qa (elastic/x-pack-elasticsearch#2432) Builds on elastic/x-pack-elasticsearch#2403 to move all of sql's integration testing into qa modules with different running server configurations. The big advantage of this is that it allows us to test the cli and jdbc with security present. Creating a project that depends on both cli and jdbc and the server has some prickly jar hell issues because cli and jdbc package their dependencies in the jar. This works around it in a few days: 1. Include only a single copy of the JDBC dependencies with careful gradle work. 2. Do not include the CLI on the classpath at all and instead run it externally. I say "run it externally" rather than "fork it" because Elasticsearch tests aren't allowed to fork other processes. This is forbidden by seccomp on linux and seatbelt on osx and cannot be explicitly requested like additional security manager settings. So instead of forking the CLI process directly the tests interact with a test fixture that isn't bound by Elasticsearch's rules and *can* fork it. This forking of the CLI has a nice side effect: it forces us to make sure that things like security and connection strings other than `localhost:9200` work. The old test could and did work around missing features like that. The new tests cannot so I added the ability to set the connection string. Configuring usernames and passwords was also not supported but I did not add support for that, only created the failing test and marked it as `@AwaitsFix`. Original commit: elastic/x-pack-elasticsearch@560c6815e3e03306270a2affd758763f34613891
2017-09-21 09:58:52 -04:00
integTestRunner {
systemProperty 'tests.cli.fixture', "${ -> cliFixture.addressAndPort }"
finalizedBy cliFixture.stopTask
}
task run(type: RunTask) {
distribution = 'zip'
plugin project(':x-pack-elasticsearch:plugin').path
setting 'xpack.monitoring.enabled', 'false'
setting 'xpack.ml.enabled', 'false'
setting 'xpack.watcher.enabled', 'false'
setting 'script.max_compilations_rate', '1000/1m'
dependsOn cliFixture
}
run.finalizedBy cliFixture.stopTask
}
}