Replace libcompose by a docker compose wrapper#7822
Conversation
jsoriano
added
in progress
There was a problem hiding this comment.
comment on exported method Project.Wait should be of the form "Wait ..."
There was a problem hiding this comment.
exported const AnyState should have comment (or a comment on this block) or be unexported
There was a problem hiding this comment.
comment on exported method Project.Wait should be of the form "Wait ..."
There was a problem hiding this comment.
exported const AnyState should have comment (or a comment on this block) or be unexported
jsoriano
force-pushed
the
docker-compose-wrapper
branch
from
d15a921 to
d881852
Compare
|
This should resolve #5050. So this can be removed too: beats/dev-tools/jenkins_ci.ps1 Lines 27 to 28 in 9664bf4 |
jsoriano
force-pushed
the
docker-compose-wrapper
branch
from
2363133 to
49b2d7d
Compare
jsoriano
force-pushed
the
docker-compose-wrapper
branch
from
dc2bdc9 to
2b9d603
Compare
jsoriano
added
review
and removed
in progress
|
Tests were failing here by a side effect we had caused by having different compose versions. compose up can decide to recreate a container if it was created with a different version, this was happening in python tests when the containers had been started by go tests, and stopped happening when I replaced libcompose. |
|
|
||
| RUN pip install --upgrade pip | ||
| RUN pip install --upgrade setuptools | ||
| RUN pip install --upgrade docker-compose==1.21.0 |
There was a problem hiding this comment.
I think we should update this also in our docs in a follow up PR: https://www.elastic.co/guide/en/beats/devguide/current/beats-contributing.html#running-testsuite
ruflin
left a comment
ruflin
left a comment
There was a problem hiding this comment.
WFG
++ on only relying on 1 library / command for the testing especially if libcompose is not maintained.
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)
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)
4 participants
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).