Cherry-pick #7822 to 6.x: Replace libcompose by a docker compose wrapper#7984
Merged
ruflin merged 1 commit intoelastic:6.xfrom Aug 20, 2018
Merged
Cherry-pick #7822 to 6.x: Replace libcompose by a docker compose wrapper#7984ruflin merged 1 commit intoelastic:6.xfrom
ruflin merged 1 commit intoelastic:6.xfrom
Conversation
Replace libcompose by a docker compose wrapper to be able to use newer features, and to give a step towards having a unified go-based integration test framework. Docker compose has multiple implementations, mainly: * docker-compose itself (python) * libcompose (go) * docker swarm services (go) We are currently using docker-compose and libcompose in tests. docker-compose for python tests, and libcompose for go tests. libcompose has some problems, it is released as experimental, and its support is quite limited, specially with new features as it only supports till version 2.0 of the [compose file format](https://docs.docker.com/compose/compose-file/#reference-and-guidelines). We are already using docker compose 2.1 version in libbeat, so we cannot have integration tests implemented in go using libcompose. docker swarm services implementation of docker compose supports more recent file formats, but is limited by the features not supported by docker swarm. It also requires docker swarm, what is not always convenient. Wrapping docker-compose from go is not ideal, but docker-compose at the moment is the only maintained and complete implementation. The wrapping code is "hidden" behind interfaces, so implementation could be replaced by some other thing in the future (though it is quite coupled to docker and compose at the moment). (cherry picked from commit 6ef073f)
Member
Author
|
jenkins, test this again please |
Member
Author
|
jenkins, test this |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cherry-pick of PR #7822 to 6.x branch. Original message:
Replace libcompose by a docker compose wrapper to be able to use newer features, and to give a step towards having a unified go-based integration test framework.
Docker compose has multiple implementations, mainly:
We are currently using docker-compose and libcompose in tests. docker-compose for python tests, and libcompose for go tests.
libcompose has some problems, it is released as experimental, and its support is quite limited, specially with new features as it only supports till version 2.0 of the compose file format. We are already using docker compose 2.1 version in libbeat, so we cannot have integration tests implemented in go using libcompose.
docker swarm services implementation of docker compose supports more recent file formats, but is limited by the features not supported by docker swarm. It also requires docker swarm, what is not always convenient.
Wrapping docker-compose from go is not ideal, but docker-compose at the moment is the only maintained and complete implementation. The wrapping code is "hidden" behind interfaces, so implementation could be replaced by some other thing in the future (though it is quite coupled to docker and compose at the moment).