This restores minimal test coverage for Postgres 9.4 (after #59 upgraded the build to Postgres 9.5): it ensures that the Docker build will build extensions against both 9.4 and 9.5, and that the smoke test runs against both versions.
This is a rather ugly way of doing it that requires 9.4-specific duplicates of Dockerfile.{build,postgres}, since we need to build the extension for the appropriate version of Postgres. That also means the
actual test suite does the job of ensuring (some) tests are run for both Postgres versions, rather than just doing a matrix build on Travis.
We could clean this up with Docker build arguments as supported by Docker 1.10+ and Docker Compose 1.6+. Then we could set the Postgres version in an environment variable and pass it into the Docker build as an argument.
However, that requires fiddling with the Travis setup to upgrade Docker, and would break the Docker build for anyone using older versions of the Docker tools (including myself). Therefore punting on that for now. (We'll probably have to do it at some point, since we're starting to get build issues reported with newer Docker versions, especially as the Docker images we depend on change to assume new Docker features - see #78, #79, #88.)
This restores minimal test coverage for Postgres 9.4 (after #59 upgraded the build to Postgres 9.5): it ensures that the Docker build will build extensions against both 9.4 and 9.5, and that the smoke test runs against both versions.
This is a rather ugly way of doing it that requires 9.4-specific duplicates of Dockerfile.{build,postgres}, since we need to build the extension for the appropriate version of Postgres. That also means the actual test suite does the job of ensuring (some) tests are run for both Postgres versions, rather than just doing a matrix build on Travis.
We could clean this up with Docker build arguments as supported by Docker 1.10+ and Docker Compose 1.6+. Then we could set the Postgres version in an environment variable and pass it into the Docker build as an argument.
However, that requires fiddling with the Travis setup to upgrade Docker, and would break the Docker build for anyone using older versions of the Docker tools (including myself). Therefore punting on that for now. (We'll probably have to do it at some point, since we're starting to get build issues reported with newer Docker versions, especially as the Docker images we depend on change to assume new Docker features - see #78, #79, #88.)