I’m usually very hesitant to use PostGIS because it makes testing more difficult. Instead of an in-memory sqlite database, you have to spin up and down a database instead. I decided to do it anyways, and then I forgot I had Travis CI on this project and every commit emailed me a reminder of my failure.
Luckily, a cursory search uncovered that Travis CI has support for PostGIS. And even luckier for me, it wasn’t that hard to do. I started with this blog post, and ended up with this as my .travis.yml:
language: python addons: postgresql: "9.3" env: PYTHONPATH='.' install: "pip install -r requirements-dev.txt" before_script: - psql -U postgres -c 'CREATE DATABASE tx_lobbying;' - psql -U postgres -c "CREATE EXTENSION postgis" -d tx_lobbying - psql -U postgres -c "CREATE EXTENSION postgis_topology" -d tx_lobbying script: make test
The postgresql: "9.3" line wasn’t even necessary, but according to their docs, Travis CI uses Postgres 9.1 by default, and I’m using 9.3. The only other change I had to make was tangential: I still had my settings set to use a SQLite database by default, but I should have made it default to a PostGIS instead.
I feel like I should mention more about what I did in my settings.py since I’m writing this specifically about GeoDjango, but I don’t think the changes I made really had much to do getting it to run of Travis CI.
According to the Testing GeoDjango docs, the Django test runner would have created a test_tx_lobbying database based off a template_postgis Postgres template, but I short-circuited that logic on Travis CI and ended up with a solution that did not involve messing with Postgres templates.
Now that I’ve done it once, and it wasn’t horrible, I plan on doing more things with GeoDjango that I’ve hesitated to do before. Now to find a cheap way to host toy PostGIS projects.
Reference: https://github.com/texastribune/tx_lobbying/commit/b7119580e4cd4b6c61fc992cc5a4fc6222c6483e