Add Docker test environment for easy development.

Add a Dockerfile with a Postgres build environment as well as simple
scripting to make it easy for contributors to quickly iterate on
extension development without needing to configure a build environment.

Unfortunately I can't easily add the Docker setup to the Makefile (as
it's normally common to do) since the existing Makefile requires the
full Postgres extension build environment, which would defeat a lot of
the purpose of the Docker environment in the first place.

Author: jcoleman

Dockerfile

@@ -0,0 +1,13 @@
+FROM postgres:12
+
+RUN apt-get update \
+    && apt-get -y install \
+      build-essential \
+      postgresql-server-dev-all \
+      postgresql-server-dev-12
+
+RUN apt-get update && apt-get -y install postgresql-12-pgtap
+
+COPY build_for_tests.sh /
+
+RUN echo "max_locks_per_transaction = 128" >> /postgresql.conf

build_for_tests.sh

@@ -0,0 +1,11 @@
+#! /bin/bash
+
+cd /home/pg_partman
+
+make && make install
+
+psql -U postgres -c "DROP DATABASE IF EXISTS partman_test"
+psql -U postgres -c "CREATE DATABASE partman_test"
+psql -U postgres -d partman_test -c "CREATE EXTENSION pgtap"
+psql -U postgres -d partman_test -c "CREATE SCHEMA partman"
+psql -U postgres -d partman_test -c "CREATE EXTENSION pg_partman SCHEMA partman"

test/README_test.md

@@ -26,6 +26,27 @@ Once that's done, it's best to use the **pg_prove** script that pgTAP comes with
 
 Most tests must be run by a superuser since roles & schemas are created & dropped as part of the test. There is a separate test script for each of the partitioning types. The tests are not required to run pg_partman, so if you don't feel safe doing this you don't need to run the tests. But if you are running into problems and report any issues without a clear explanation of what is wrong, I will ask that you run the test suite so you can try and narrow down where the problem may be. You are free to look through to tests to see exactly what they're doing. All tests in the top level of the test folder are run inside a transaction that is rolled back, so they should not change anything (except jobmon logging as mentioned).
 
+## Docker Environment
+
+If you don't have a build environment setup on your local machine, the project provides a docker container setup for your convenience. As long as Docker is installer, you can use the following commands to run tests:
+
+    # Build and start container (must be run in the project root):
+    docker build -t partman_test_image .
+    docker run -d --name partman_test -v $(pwd):/home/pg_partman partman_test_image
+
+    # Logon to container shell:
+    docker exec -it partman_test bash
+
+    # For each test cycle (on the container shell):
+    /build_for_tests.sh
+    pg_prove -ovf -U postgres -d partman_test /home/pg_partman/test/<test_file_path>.sql
+
+    # Tear down container:
+    docker stop partman_test
+    docker rm partman_test
+
+The Docker container volumizes the project working directory so that any changes to your local copy of the project are reflected immediately on the container. This volumization allows rapid iteration without stopping and starting the container frequently. The [build_for_tests.sh](build_for_tests.sh) script automatically rebuilds the extension, installs it, and creates a fresh database with both pgTAP and the project extension installed.
+
 ## Specific Test Types
 
 Tests for the time-custom partition type are in their own folder. The 30second test frequently errors out if run in certain 30 second blocks. Waiting for the next 30 second block and running it again should allow it to pass. Same goes for the 30 second test in the native folder.