Public | Automated Build

Last pushed: a month ago
Short Description
Test environment for GeoDjango projects with PostGIS and SpatiaLite support out of the box.
Full Description

Docker for GeoDjango with PostGIS and SpatiaLite

Test environment for GeoDjango projects with PostGIS and SpatiaLite support out of the box.

BitBucket Pipelines support

You can use this as a test image with BitBucket Pipelines, an example:

image: wooyek/geodjango:ubuntu-16.04

    - step:
        # Pipelines overrides default docker entry point, we need to run it maually
        - tox

Tox support

Tox is is the best way to encapsulate your tests, here's an example:

envlist = py35,py27
skipsdist = True

passenv =

setenv =
    TOX_ENVBINDIR = {envbindir}
    LIBRARY_PATH = /usr/local/lib

commands =
    coverage erase
    coverage run test
    coverage report
    coverage xml

deps =

Build docker image

If you don't have Docker installed,
you can use Vagrant development environment:

vagrant up
vagrant ssh

Replace wooyek/geodjango with your own image name, replace /vagrant/ with a proper path if you don't use Vagrant:

docker build -t wooyek/geodjango /vagrant/
docker push wooyek/geodjango

Run and test

We can always check docker machine environment variables
by this command (you should see default values set in Dockerfile):

docker run --rm wooyek/geodjango env

We can use host environment, but we still need to to pass environment variable names in a command.

I find the cleaniest easiest way is to create a separate file containing all the environment variables.
Let's prepare our environment file with some variable substitution from a sample file.
This is a one time operations.

source <(sed -E 's/[^#]+/export &/' ${ENV_FILE})
envsubst < ${ENV_FILE} | tee /vagrant/environment.env

Let's check them out:

docker run --rm --env-file /vagrant/environment.env wooyek/geodjango env

Now we can run tests from a sample project. We will map local vagrant folder to a docker volume
to make them accessible from inside a running container. We'll also override DJANGO_SETTINGS_MODULE to point to all-in-one settings file,
instead of more specialized website.settings.testing module used when settings are split info multiple modules:

docker run --rm -it --name qa \
    --volume=/vagrant:/vagrant \
    --workdir="/vagrant" \
    --memory=4g \
    --memory-swap=4g \
    --entrypoint=/bin/bash \
    --env-file /vagrant/environment.env \
    --hostname ${HOSTNAME} \
    -e DJANGO_SETTINGS_MODULE=website.settings \
    wooyek/geodjango \ tox -c /vagrant/sample/awesome-project

There should be a one passed test filtering on distance.


Docker images take some space, if you need to clear that out use one of those prune commands:

docker system prune
docker image prune
docker container prune
Docker Pull Command
Source Repository