Configure PostGIS With Travis CI
Thanks to a great presentation by foundatron on the continuous integration framework, Travis CI, I’ve finally been motivated to push for higher test coverage in my python projects.
Some of these projects require connectivity to a PostGIS database for testing, and with Travis CI that process is extremely straightforward. This post includes notes on configuring a Travis CI environment with PostgreSQL and PostGIS, then loading that empty database with data.
NOTE: These versions are current as of January 2014.
- PostgreSQL: 9.1.11 by default, although you can explicitly declare 9.2 or 9.3.
- PostGIS: 2.1.1 r12113
- GEOS: 3.3.8
- PROJ: 4.8.0
- GDAL: 1.9.2
NOTE: For background reading on Travis CI, check out the Getting Started and Build Configuration docs.
As stated in the database docs,
a Travis CI environment comes with PostgreSQL installed and ready-to-go. This also includes supporting
utilities such as:
pg_restore. Since we’re using PostgreSQL 9.1+ and PostGIS 2.0+,
PostGIS can be installed using the
CREATE EXTENSION syntax.
.travis.yml configuration file should now be modified to execute
psql calls in the
before_script block to:
- Create the database
- Create the PostGIS/PostGIS Topology Extensions
- Populate the database with test data. (See Below for Instructions)
A reference example
.travis.yml looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Creating Test Data
pg_dump utility can be used to export the contents of a PostGIS database into a sql file,
suitable for loading into a newly created database by the Travis worker. Key to this is to have testing
data that you want to export inside of a separate schema (e.g. not in
pg_dump we can
specify an individual schema of data tables to export, otherwise we’d be stuck with exporting potentially
incompatible PostGIS function signitures in addition to our data. Boundless has a
good article on backup strategies for PostGIS.
From our source PostGIS database, export tables from our schema of interest (
As seen in the section above, the resulting sql file,
test_data.sql is then executed as part of the
before_script block, populating the testing database with geometries.
NOTE: I’ve used the same name
travis_postgis for both my local database as well as the testing
database used by Travis CI. This isn’t required.
Thanks to the combination of PostgreSQL’s easy to use
CREATE EXTENSION syntax along with Travis CI’s flexible build configurations, setting up a custom PostGIS database is fairly simple.
An example repository with a
.travis.yml file and an example unit test can be found here: https://github.com/mattmakesmaps/travis-postgis-test
This repository’s Travis CI build log can be found here: https://travis-ci.org/mattmakesmaps/travis-postgis-test