-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Use TestFixturesPlugin to Run Minio in Tests #37852
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
Use TestFixturesPlugin to Run Minio in Tests #37852
Conversation
original-brownbear
commented
Jan 25, 2019
- Closes [CI] minio fails due to port clashes #37680
- Closes Use TestFixturesPlugin to Spin up Minio in S3 Plugin Tests #37783
|
Pinging @elastic/es-distributed |
| } | ||
| minioDockerfile.parentFile.mkdirs() | ||
| minioDockerfile.text = "FROM minio/minio:RELEASE.2019-01-23T23-18-58Z\n" + | ||
| "RUN mkdir -p /minio/data/${s3PermanentBucket}\n" + |
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 chose to dynamically build the Dockerfile here since we need to create this directory in the container somehow to force the existence of a bucket.
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.
Would it make sense to have hard coded values for bucket, access and secret keys in case we use minio so the test always runs ? Could also be in a follow up, but that way we would not need a docker file at all as we can just include the hard-coded values in the docker compose configuration and mount a volume that already has a directory for the bucket. I don't think this is a blocker to merge this PR, but would be good to have this test running with the regular 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.
Do we want to use local fs volume mounts though? I'd rather not, that's gonna be a little annoying for environments (like my personal CI :D) that use Docker in Docker or a remote Docker daemon?
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 not sure this will work in docker based local CI right now and the tests will just be skipped. I'm not sure we can avoid the volume mounts for all fixtures anyway, but maybe we can create the dirs as part of the start command ?
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 not sure this will work in docker based local CI right now
Works for me :D You just gotta mount the docker socket right and it all works fine :)
I'm not sure we can avoid the volume mounts for all fixtures anyway
I'd vote for maybe just adding some way of copying dirs in and (if needed) out of the containers via Gradle (tasks). That would be completely portable.
Also, it would avoid some foreseeable weirdness, where we'd create root owned files in the volumes through the containers and then can't delete them in ./gradlew clean :)
maybe we can create the dirs as part of the start command?
annoyingly enough we can't do that I think, because of the weird way the official container sets up the environment (we're only supplying the args to command right now).
Also, for #37393 I'd love to be able to be a little more flexible here and maybe create multiple containers with different bucket names.
|
thanks @original-brownbear for taking this up! I'm glad to see that code in |
|
@atorok thanks for taking a look, changed the task dependency relations as requested and removed the container shutdown now :) |
alpar-t
left a comment
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
|
@atorok thanks! |
* Disable Minio fixture and tests that require it whne fixtures are disabled or Docker is not available * Relates elastic#37852
* Disable Minio fixture and tests that require it when fixtures are disabled or Docker is not available * Relates #37852
* Use TestFixturesPlugin to Run Minio in Tests * Closes elastic#37680 * Closes elastic#37783
* Use TestFixturesPlugin to Run Minio in Tests * Closes elastic#37680 * Closes elastic#37783
* Disable Minio fixture and tests that require it when fixtures are disabled or Docker is not available * Relates elastic#37852
* Use TestFixturesPlugin to Run Minio in Tests (#37852) * Use TestFixturesPlugin to Run Minio in Tests * Closes #37680 * Closes #37783 * Fix S3 Repository ITs When Docker is not Available (#37878) * Disable Minio fixture and tests that require it when fixtures are disabled or Docker is not available * Relates #37852 * add explicit composeUp dependsOn