-
Notifications
You must be signed in to change notification settings - Fork 25.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Proposal to replace fixtures with docker-compose #35651
RFC: Proposal to replace fixtures with docker-compose #35651
Conversation
This is a non working example to request feedback on the general direction before mooving forward with thease tools. We can easily support random ports with this setup as the Gradle plugin exposes a map of the randomly assigned ports.
Pinging @elastic/es-core-infra |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea. It'd be nice to know:
- If docker isn't installed, can we still skip the tests like we do with vagrant?
- Is it possible that it'd work on Windows? It looks like Docker has a thing for Windows.
I think a good next thing to check is "how do random ports work?"
x-pack/test/smb-fixture/build.gradle
Outdated
* Allows for other subprojects to depend on the project level and not care about the details | ||
* of composeUp | ||
*/ | ||
jar { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems funky. I think I'd prefer to depend on the task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't fully convinced either, just wanted to bring it up. Let's do the task it's more straight forward.
|
Thanks for taking a look @nik9000 I'm glad you like it. I made changes to show how remote ports could work. I'm thinking of pulling it into a plugin, to avoid repetition throughout the build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love the idea.
One thing that bothers me a little is that we're already actively moving away from tasks to manage test clusters and this seems to use tasks to manage docker. The docker images are going to be much lighter than our test clusters so it is probably ok, but it does feel bad.
systemProperty 'es.set.netty.runtime.available.processors', 'false' | ||
include '**/*IT.class' | ||
include '**/*Tests.class' | ||
doFirst { | ||
fixtureProject.dockerCompose.servicesInfos.fixture.ports.forEach { container, host -> | ||
logger.info(" adding system property fixture.smb-fixture.ports.$container -> $host") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should move this to debug
? It is nice to have but maybe not all the time.
@@ -46,13 +46,14 @@ | |||
// as we cannot control the URL of the referral which may contain a non-resolvable DNS name as | |||
// this name would be served by the samba4 instance | |||
public static final Boolean FOLLOW_REFERRALS = Booleans.parseBoolean(getFromEnv("TESTS_AD_FOLLOW_REFERRALS", "false")); | |||
public static final String AD_LDAP_URL = getFromEnv("TESTS_AD_LDAP_URL", "ldaps://localhost:61636"); | |||
public static final String AD_LDAP_GC_URL = getFromEnv("TESTS_AD_LDAP_GC_URL", "ldaps://localhost:63269"); | |||
public static final String AD_LDAP_URL = getFromEnv("TESTS_AD_LDAP_URL", "ldaps://localhost:" + getFromProperty("636")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe name them rather than use the original port number? As much as I love port numbers I think it'd be nicer to call them LDAP
and LDAP_GC
or something.
x-pack/test/smb-fixture/build.gradle
Outdated
environmentVars vagrantEnvVars | ||
buildscript { | ||
repositories { | ||
jcenter() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think jcenter
is already in our build script.
x-pack/test/smb-fixture/build.gradle
Outdated
dependsOn halt | ||
task info() { | ||
dependsOn composeUp | ||
doLast { println dockerCompose.servicesInfos.fixture.ports } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this do compose down after?
That makes sense to me! I think before we merge this we should get that docker detection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very happy with this as a better approach than vagrant, especially because it fixes the longstanding issue of hardcoded ports. Other than making sure this works in elasticsearch-ci
, I just have one little nit.
systemProperty 'es.set.netty.runtime.available.processors', 'false' | ||
include '**/*IT.class' | ||
include '**/*Tests.class' | ||
doFirst { | ||
fixtureProject.dockerCompose.servicesInfos.fixture.ports.forEach { container, host -> | ||
logger.info(" adding system property fixture.smb-fixture.ports.$container -> $host") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can you use ${container}
so it is clear where the substitution ends vs string value? Same below with the actual system property.
…tures-docker-compose
…tures-docker-compose
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I muted the failing tests since CI already has docker-compose. Added the |
@elasticmachine test this please |
…tures-docker-compose
The conainer images are cached making subsequent runs faster.
Note to self. When this is merged, should add an issue to add fixtures for some projects like: x-pack/qa/third-party/jira/build.gradle which require an external one so these can run in regular CI. |
@rjernst do you want to take another look ? I made some changes after you approved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, one nit
@@ -0,0 +1,12 @@ | |||
FROM ubuntu:16.04 | |||
RUN apt-get update -qqy && apt-get install -qqy samba ldap-utils |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that installsmb.sh
is being run in the docker file, I think installing samba and ldap-utils should move back into there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion on that, and don't mind doing it in a follow up.
One advantage of keeping these separate is that one can iterate on the install script without waiting for apt all the time, but having everything in the same script is also nice.
Creates a new plugin to manage docker-compose based test fixtures. Convert the smb-fixture as a first example.
This is a non complete example to request feedback on the general
direction before mooing forward with these changes.
It's lacking detect and skip functionality and causes the containers to go up even when they are not needed, but these are workable if we find the general approach ok.
We can easily support random ports with this setup as the Gradle plugin exposes a map of the randomly assigned ports, it's just a matter of passing them to the tests.
The plugin being used is documented here: https://github.com/avast/gradle-docker-compose-plugin
Relates to #34095