Recently I have written about how one can create a PostgreSQL Docker
image with the Docker Maven Plugin to run integration tests that
require a database. While this worked all nice and well during
development, the concept has one flaw: the plugin will push the
database Docker image to a Docker registry during the
I do not want this temporary image to end up there. This is the
behavior of the Docker Maven Plugin and I have not found a way to
work around this. By “work around this” I mean somehow configure
the plugin to ignore this custom PSQL image during the “deploy”
phase. Unfortunately, there is only a global
<filter> that applies
to all the phases of the plugin.
There is a proper solution however, at least for what I was using the database.
If you need to customize your database Docker image more than I do then this will not help you. What I want is the following:
- Create a separate database
- Have a dedicated database user with its own password
By default, the standard database is
postgres and the user is also
postgres. I do not want that. I want my application to use similar
settings in integration tests as are used in production.
Instead of creating a custom PostgreSQL image in the
plugin -> configuration -> images -> image section that injects a SQL file
into the bootstrap process of the PSQL server you can configure the
name of the database, the user and its password when the container is
launched during the
<goal> in the
executions -> execution
section. Another important change is in the
<name> element. In now
holds the name and version of the Docker image to pull and start.
<execution> <id>start-postgres</id> <phase>pre-integration-test</phase> <goals> <goal>start</goal> </goals> <configuration> <images> <image> <alias>it-database</alias> <name>postgres:9.4</name> <run> <ports> <port>it-database.port:5432</port> </ports> <env> <POSTGRES_USER>docker_db_testing_tests</POSTGRES_USER> <POSTGRES_PASSWORD>docker_db_testing_tests</POSTGRES_PASSWORD> <POSTGRES_DB>docker_db_testing_tests</POSTGRES_DB> </env> <wait> <log>(?s)database system is ready to accept connections.*database system is ready to accept connections</log> <time>20000</time> </wait> </run> </image> </images> </configuration> </execution>
I have created another commit to the repository of the original blog post that has this fix.
Keep in mind that the repository is set up in way that is designed to
db/migrations folder holds two database scripts, the
second of which results in an error during
mvn verify. Testing
database migrations was the driving motive behind this setup. Remove
the second migration script and the tests will pass without failure.