testcontainers / testcontainers/testcontainers-java

Container lifecycle management as Maven and Gradle plugins

オープン
#4,397 コメント 4 件 リアクション 181 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
Java
スター
8.7k
フォーク
1.9k
平均マージ
2日 17時間
マージ済み PR(30日)
9

説明

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

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、リンクされている squark-io/testcontainers-maven-plugin の例と、ここで説明されている Maven および Gradle のライフサイクル要件を確認すること。設定可能なコンテナの起動および停止ゴールをビルドフェーズにどのように統合するかを定義し、ビルドが早期に終了した場合のクリーンアップも含めること。Flyway、Liquibase、jOOQとは独立して、両方のプラグイン統合が提案されたライフサイクルをサポートすれば完了とする。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
docker, java
領域
build-system, devops, testing
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。