feat: add RabbitMQ support #1618
Conversation
mdelapenya
added
the
feature
✅ Deploy Preview for testcontainers-go ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
modules/rabbitmq/rabbitmq.go
Outdated
| // listed below are deprecated and no longer used. Please use a configuration file instead; | ||
| // visit https://rabbitmq.com/configure to learn more about the configuration file. For a starting point, | ||
| // the 3.8 images will print out the config file it generated from supplied environment variables. | ||
| func WithSSL(sslSettings SSLSettings) testcontainers.CustomizeRequestOption { |
There was a problem hiding this comment.
take into account the following PR comment
There was a problem hiding this comment.
I've not implemented yet the SSL improvements. Should I proceed with the current state or rework the PR to remove the usage of the deprecated variables. It will define the lower version of RabbitMQ to use: +3.9
There was a problem hiding this comment.
IMO new Testcontainers implementations should take into account the most generic and compatible approach. In this case, using the configuration file is an option which will work for versions older than 3.9 and new ones. The implementation will differ from Testcontainers for Java but I think it will be a good one too
There was a problem hiding this comment.
Makes sense. I will use that PR comment for the implementation. One thing I noticed regarding the env_vars: at this moment, the RabbitMQ module in tc-java, using SSL and setting the image to +3.9, will fail with a deprecation notice.
We do not want to be specific, but generic
* main: fix: proper next version chore: prepare for next minor development cycle () chore: use new version (v0.24.0) in modules and examples fix: include sonarcloud file into the release commit modulegen: generate sonar configuration (testcontainers#1644) feat: define test session semantics (testcontainers#1513) chore(deps): bump actions/checkout from 3 to 4 (testcontainers#1623)
We are gonig to build our own config
* main: docs: have common options in a common markdown file (testcontainers#1648) feat: add functional option for startup commands (testcontainers#1647) fix: support running the semver Docker image interactively (testcontainers#1646) fix: proper next version chore: prepare for next minor development cycle () chore: use new version (v0.24.1) in modules and examples fix: avoid deadlocks when Docker is not available (testcontainers#1645)
|
@eddumelendez I think this is ready to Go! |
|
@eddumelendez we are going to merge this, and because it's not released yet, we can improve it in follow-up PRs. |
What does this PR do?
This PR adds the RabbitMQ module, using Java module as reference implementation: all the options are implemented (see docs site)
It also fixes docs in postgres (a block that was removed) and the examples template, wording.
To implement the execution of startup commands, as demonstrated in the testable examples for this module, we are consuming the
testcontainers.WithStartupCommandfunctional option from the core, which accepts a variadic argument oftestcontainers.Executable. The latter is an interface with one single method:AsCommand() []string. Therefore, users of the RabbitMQ module (and eventually any other module) will be able to run arbitrary commands on the container right after it has started. The users will be responsible of creating valid commands.NOTE: we are sharing some examples on how to create those commands. Please take a look at the
types_test.gofile.All the options in the RabbitMQ module will be rendered into a
.conffile, which will be the default configuration for the RabbitMQ container. We will leverage Go templates to render this conf file.Why is it important?
More modules!