Add InfluxDB module - #1445

✅ Deploy Preview for testcontainers-node ready!

Name	Link
🔨 Latest commit	005620e
🔍 Latest deploy log	https://app.netlify.com/projects/testcontainers-node/deploys/6ab6881844760e000866859f
😎 Deploy Preview	https://deploy-preview-1445--testcontainers-node.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

Merge Risk: ⚪ Minimal · up to bce6d

The previous version-selection and token-access concerns are addressed by the separate containers and exposed default token. No actionable merge-blocking risk remains after normal checks.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Hi @JonnasFigueiredo, thanks for raising the PR. Apologies in the delay in reviewing it. A few issues:

1. Split into one class per major version

Right now the version is guessed from the image tag, and anything that doesn't parse as 1.x is treated as 2.x. That breaks on several official tags that exist today:

• 3-core, 3.11-core, core and enterprise are InfluxDB 3. They get the 2.x setup, and influxdb:3-core hangs until the startup timeout ("URL /ping not accessible").
• data, meta and data-alpine are 1.x Enterprise, and they're also configured as 2.x.

Instead of making the tag parsing stricter, I'd prefer separate classes in this same package:

export { InfluxDB1Container, StartedInfluxDB1Container } from "./influxdb1-container";
export { InfluxDB2Container, StartedInfluxDB2Container } from "./influxdb2-container";

This also:

• gets rid of getters that mean nothing for one of the versions (getOrganization()/getBucket() on 1.x, getDatabase() on 2.x) and the isInfluxDB2() check;
• leaves room for an InfluxDB3Container later. The open 3.x PRs in Java and Python both add a separate class, because 3.x uses a different port (8181), startup command and token model.

2. InfluxDB 2.x: set a default admin token

If withAdminToken() isn't called, getAdminToken() returns undefined. InfluxDB does generate a token, but there's no easy way to read it back, so the client can't be used out of the box. Please set a default token, so the getter can return string and the zero-config path just works.

3. InfluxDB 1.x: the defaults don't give a usable user

With the defaults (auth on, no database), the created user can't do anything: CREATE DATABASE returns 403 ("requires admin privilege"), and the admin credentials aren't exposed. The docs example avoids this with withAuthEnabled(false), so the default path isn't tested. I'd suggest defaulting the database (e.g. test) so the user gets privileges on it, and adding getAdminUsername() / getAdminPassword().

4. Tests

• The 1.x test can't fail. InfluxDB returns 200 even for errors (for example {"results":[{"statement_id":0,"error":"database not found: nope"}]}), so expect(body.results).toBeDefined() passes even if the write went nowhere. Please assert that the written point comes back.
• "should apply custom configuration" only checks that the getters return what was set. It would still pass if the settings never reached the container. Writing and querying with the custom token/org/bucket would test it for real.
• Please also add a test for the default 1.x path with auth enabled.

5. Nits

• The class comment says tags "below 2" are treated as 2.x; the code does the opposite. (This goes away with the split.)
• Please bump the images to the current lines: influxdb:2.9 and influxdb:1.13.
• The docs say to substitute IMAGE, but the examples use INFLUXDB2_IMAGE / INFLUXDB1_IMAGE.
• Optional: 2.x setup rejects passwords shorter than 8 characters, but that only shows up in the container logs, and the caller waits out the full 120s timeout. A length check in start() would fail fast.

Happy to help with any of this.

Thanks for the detailed review, @cristianrgreco! I've addressed the points in 68bd0ee: split the classes by major version, fixed the default token and database setup, exposed the 1.x admin credentials, strengthened the integration tests, and updated the images and documentation. I also added the short-password validation.

All 9 module tests and both documentation examples pass locally against real containers, along with lint and compilation. Ready for another look whenever you have time. Thanks!

Thanks @JonnasFigueiredo, this covers everything from the last round.

One thing before merging:

• Docs: please switch back to <!--codeinclude--> with inside_block markers in the tests instead of hand-written snippets. Every other module doc includes its examples from the tests, so they're compiled and run in CI. Inline copies drift. Keep the "Choose an image from the container registry and substitute IMAGE." line like the other docs. The paragraphs describing the defaults are useful, so keep those.

Nits:

• The tests import from ./index. Other modules import from the container file directly (./influxdb1-container, ./influxdb2-container).
• influxdb1-container.test.ts repeats the Basic auth header and the expected cpu_load result in every test. A couple of small helpers in the test file would cut that down.

Done in bce6d9d. Docs are back on codeinclude with inside_block markers, the tests import from ./influxdb1-container and ./influxdb2-container, and the repeated Basic auth header and cpu_load result are helpers now. I left the header and the expected payload inline in the first 1.x test on purpose, since that is the block the docs pull in.

9 tests pass locally and mkdocs build --strict renders both blocks. The deploy preview is red, but the docs build fine here and that site also errored on a few dependabot PRs, so it looks unrelated. Could you retry it?

The red jobs on this run are the 4 minio ones, not influxdb. They fail before starting a container, because quay.io/minio/minio is private now: unauthorized: access to the requested resource is not authorized. It hits every PR and main, so I opened #1466 with a fix. All influxdb jobs here are green.