testcontainers-java

testcontainers-java copied to clipboard

Every item on this list will require judgement by the Testcontainers core maintainers. Exceptions will sometimes be possible; items with should are more likely to be negotiable than those items with must.

Default docker image

• [x] Should be a Docker Hub official image, or published by a reputable source (ideally the company or organisation that officially supports the technology)
• [ ] Should have a verifiable open source Dockerfile and a way to view the history of changes
• [x] MUST show general good practices regarding container image tagging - e.g. we do not use latest tags, and we do not use tags that may be mutated in the future
• [x] MUST be legal for Testcontainers developers and Testcontainers users to pull and use. Mechanisms exist to allow EULA acceptance to be signalled, but images that can be used without a licence are greatly preferred.

Module dependencies

• [x] The module should use as few dependencies as possible,
• [x] Regarding libraries, either:
• they should be compileOnly if they are likely to already be on the classpath for users' tests (e.g. client libraries or drivers)
• they can be implementation (and thus transitive dependencies) if they are very unlikely to conflict with users' dependencies.
• [x] If client libraries are used to test or use the module, these MUST be legal for Testcontainers developers and Testcontainers users to download and use.

API (e.g. MyModuleContainer class)

• [x] Favour doing the right thing, and least surprising thing, by default
• [x] Ensure that method and parameter names are easy to understand. Many users will ignore documentation, so IDE-based substitutes (autocompletion and Javadocs) should be intuitive.
• [x] The module's public API should only handle standard JDK data types and MUST not expose data types that come from compileOnly dependencies. This is to reduce the risk of compatibility problems with future versions of third party libraries.

Documentation Every module MUST have a dedicated documentation page containing:

• [x] A high level overview
• [x] A usage example
• [x] If appropriate, basic API documentation or further usage guidelines
• [x] Dependency information
• [x] Acknowledgements, if appropriate
• [x] Consider that many users will not read the documentation pages - even if the first person to add it to a project does, people reading/updating the code in the future may not. Try and avoid the need for critical knowledge that is only present in documentation.

@bsideup @kiview @rnorth Hi All, There is a lot of interest in our community to get YugabyteDB support in TestContainers project, please let us know what are steps required for getting the following PR merged and bringing support for YugabyteDB in Testcontianers project. Thanks, Nikhil

Hi, We're about to start using yugabyte in our project. Is there an ETA on this PR ?

@bsideup @kiview @rnorth - Pls let us know if you need anything from our side to get this PR reviewed and merged. There is a lot of interest in the YB community to use this. Thnx.

Thanks for the PR @srinivasa-vasu ! LGTM overall but WDYT about having YugabyteContainer only and provide something like withAPI(YugabyteAPI.YSQL), withAPI(YugabyteAPI.YCQL)?

@eddumelendez - Thanks for reviewing this. The APIs' are different, one is fully relational, and the other is semi and Cassandra compatible. Will end up with a lot of conditional blocks. Having it separate may be a cleaner abstraction.

thanks for addressing the comments so fast! We will take a look at the changes

@srinivasa-vasu can you please add yugabyte to

• .github/ISSUE_TEMPLATE/bug_report.yaml
• .github/ISSUE_TEMPLATE/enhancement.yaml
• .github/ISSUE_TEMPLATE/feature.yaml
• .github/dependabot.yml
• .github/labeler.yml

@eddumelendez - anything pending from my side?

thank you so much for your contribution @srinivasa-vasu ! This is now in main branch and it will be part of the next release.

Thanks @eddumelendez