search

hackoregon / transportation-system-backend

2018 repo for the transportation api backend
MIT License
8 stars 2 forks source link

"No such service" when replacing api_transportation with $DOCKER_IMAGE in .travis.yml #47

Closed MikeTheCanuck closed 6 years ago

MikeTheCanuck commented 6 years ago

My last contribution before heading out to work was to replace api_production with $DOCKER_IMAGE in the .travis.yml, so that this could be a fully-generalizable .travis.yml - however, when this deployed to Travis it threw this error and then failed the test.sh tests:

0.72s$ docker-compose -f production-docker-compose.yml run --entrypoint "./manage.py collectstatic --noinput" $DOCKER_IMAGE
No such service: transportation-systems-service

I'd love to fix this myself but I won't have time until tonight, so anyone else can figure out what's wrong here, fire away.

MikeTheCanuck commented 6 years ago

I've found the two other places where api_production is hard coded and interferes with this build/test run in Travis, and I believe this is a workable pattern.

However, I'm a little unsure whether this is a pattern that reasons out well - this appears to be conflating "name of the Docker image we're using" with "name of the Docker service we're launching" - and while they're similar, and folks could probably reason it out, I'm not convinced that this is doing our future selves (or descendants) any favours.

MikeTheCanuck commented 6 years ago

This has been resolved with the following commits: de22800bfb176ee84c1e24eb40066784f977e7d4 a67d55d244eec636ec275215f30ea1aa77c8b16b

nam20485 commented 6 years ago

I am not clear on why they need to be differentiated. All the places I can find that use the docker image name all refer to it as api_production, so it seems like one Docker image name variable would suffice. This one variables controls what name the image is created with, thus should be the same value we use when we want to build, start, test, or deploy said docker image.

I have a pattern for the .env variables, image creation and run, and deployment in my nam20485/disaster-resilience-backend repo. Take a look at this PR (https://github.com/hackoregon/disaster-resilience-backend/pull/6/files), and then maybe we can use it as a place to start to discuss whether it meets your needs or not, and what changes would be required.

There are also upgrades to the deploy functionality we have been using, namely, tagging the docker images in the registry with the travis build number in addition to the "latest" tag for the currently most up to date image.