testcontainers / testcontainers/testcontainers-java

Container lifecycle management as Maven and Gradle plugins

Open
#4,397 4 comments 181 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
8.7k
Forks
1.9k
Avg merge
2d 17h
Merged PRs (30d)
9

Description

In jOOQ, one of the most re-occurring ideas is that jOOQ should tightly couple Testcontainers, Flyway/Liquibase and jOOQ's code generation. See e.g. https://github.com/jOOQ/jOOQ/issues/6551

This coupling is obviously a bad idea, because the glue code is only a few lines of code, but to make it sufficiently configurable on behalf of all 3 involved products, we'd have to go through a lot of hassle. Much better if all 3 products could be configured completely independently in a CI/CD pipeline.

This is already possible for Flyway/Liquibase and jOOQ, both in Maven and Gradle, but I think it's not trivial to do for Testcontainers yet? What I'd love to see is to have Maven and Gradle plugins available that would allow for controlling the lifecycle of a test container instance in a build, for example (in pseudo-Maven):

<plugins>

  <!-- Start the database container -->
  <plugin>
    <artifactId>testcontainers-postgres-maven<artifactId>
    <phase>initialize</phase>
    <goal>start</goal>
  </plugin>

  <!-- Apply all schema migrations -->
  <plugin>
    <artifactId>flyway-maven<artifactId>
    <phase>initialize</phase>
  </plugin>

  <!-- Generate jOOQ sources -->
  <plugin>
    <artifactId>jooq-codegen-maven<artifactId>
    <phase>generate-sources</phase>
  </plugin>

  <!-- Stop the containers -->
  <plugin>
    <artifactId>testcontainers-postgres-maven<artifactId>
    <phase>post-integration-test</phase>
    <goal>stop</goal>
  </plugin>
</plugin>

I don't think Maven has an equivalent of Java's finally clause (i.e. a phase that runs at the end irrespective of how many phases were run), so if the post-integration-test phase isn't reached, then the containers won't stop, but that can be handled:

  • E.g. they could stop at the latest when the build VM terminates (might be possible?)
  • Gradle might not have this problem
  • The start goal could reset the container first, if it is already running
  • They could use Maven profiles for the whole thing and put all 4 plugin executions in there

There are many details to flesh out, but you get the idea. I think the sort of versatility this offers to highly generic, configurable builds would be yet another killer feature for testcontainers, not just for testing, but for CI/CD pipelines in general.

I've found an example project here, that does something like what I have in mind:
https://github.com/squark-io/testcontainers-maven-plugin

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the linked squark-io/testcontainers-maven-plugin example and the lifecycle requirements described here for Maven and Gradle. Define how configurable container start and stop goals should integrate with build phases, including cleanup when the build ends early; done means both plugin integrations support the proposed lifecycle independently of Flyway, Liquibase, and jOOQ.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, java
Domain
build-system, devops, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.