Updated Travis scripts #12
Conversation
clintonb
commented
Dec 17, 2018
•
clintonb
commented
- We now pull images prior to building. This helps avoid wasting time completely rebuilding the app container.
- Added test to ensure migrations have been generated, and run properly.
- We wait for the database to become available before running Django management commands
clintonb
force-pushed
the
clintonb/travis-updates
branch
from
16b6a0c to
82e36bf
Compare
|
What do you think is causing: |
|
The database container hasn’t started. I thought I’d resolved this. |
|
Yeah, my understanding is still too limited to make a meaningful contribution |
- We now pull images prior to building. This helps avoid wasting time completely rebuilding the app container. - Added test to ensure migrations have been generated, and run properly. - We wait for the database to become available before running Django management commands
clintonb
force-pushed
the
clintonb/travis-updates
branch
from
6d03077 to
78362b1
Compare
|
This is ready. @TangoYankee or @r-b-g-b, please approve so that I can merge. |
|
Nice! Looks like it's behaving better now. One issue I read about involves wait-for-it.sh and the way the postgres docker containers are instantiated. wait-for-it.sh just checks that a given host:port responds. While initializing itself, the postgres container starts and stops several times before it is actually ready. It is possible that wait-for-it.sh falsely detects the postgres service during one its intermediate phases. No sense for how likely this is to ever occur, just something to keep in mind if we ever notice random failed tests. I think this looks ready to merge, thanks @clintonb ! |
|
@r-b-g-b your concern is valid in general, but not an issue in this specific case. The restart issues only apply on the first run of the database. The first line of I imagine this race condition will be fine for the foreseeable future. If any drastic changes are made to that container, we should definitely revisit this issue. |
