Testing in docker #118
Testing in docker #118
Conversation
…t.py file that gives a test env for the test containers.
…, mostly interim check in.
…z-server into testing-in-docker
It's a good idea to have it for the workers that are going to connect to an external service so that they can wait for those external containers to come up before running
Add options to start the test database containers and leave them running so that running tests during development will be faster Running the script if no containers exist will cause them to be started and set up before running the tests.
| # docker ps -a --no-trunc | grep $COMPOSE_PROJECT_NAME \ | ||
| # | awk '{print $1}' | xargs -r --no-run-if-empty docker stop | ||
| # docker ps -a --no-trunc | grep $COMPOSE_PROJECT_NAME \ | ||
| # | awk '{print $1}' | xargs -r --no-run-if-empty docker rm |
There was a problem hiding this comment.
Does this stuff need to be here (commented out)?
|
|
||
|
|
||
| if [[ ! -d "docker" ]]; then | ||
| echo "This script must be run from the top level directory of the listenbrainz-server source." |
There was a problem hiding this comment.
Can do something like this to make it easier to use: metabrainz/sir#11 (comment) (cd "$(dirname "${BASH_SOURCE[0]}")/../").
|
|
||
|
|
||
| function bring_up_db { | ||
| docker-compose -f $COMPOSE_FILE_LOC -p $COMPOSE_PROJECT_NAME up -d db influx redis |
There was a problem hiding this comment.
Why is this separation necessary when the dependencies are defined in the compose file?
There was a problem hiding this comment.
true, perhaps not needed. I originally had it because I did
docker-compose up <databases>
docker-compose run listenbrainz dockerize ... <setup db>
docker-compose up -d
docker-compose logs -f listenbrainz
then I realised that we could skip the up -d and logs and just run py.test straight from docker-compose run.
In this case, if we run docker-compose run listenbrainz dockerize ... <setup db> then it should load the database containers first, right?
|
Yes, I'd be really happy to remove docker-compose.prod.yml. The idea would be that we have docker-compose.yml for development and .test. for unit tests, right?? Do you think we also need a different Dockerfile and Dockerfile.prod? Looking at the case for LB, I think that they do 99% the same thing? |
|
You'll probably need a separate Dockerfile if you want to deploy on the new infrastructure. |
|
As a side note: if you want me to review something next time, I'd appreciate to be given more than half an hour. |
This branch fixes and cleans up the unit test setup. We now have a test.sh script that will start the needed containers and run tests in the most expedient way possible. Also, testing happens in isolated containers that do not interfere with production containers/volumes.