feat(couchbase): adding auth to couchbase initCluster functions to support container reuse

[waroir20]

What does this PR do?

This PR aims to enable a created couchbase container to be reused between test packages, and accomplishes this by passing the basic auth header with every request made to the container's management ports.

Why is it important?

Since Go's test context creates physically separated binaries between packages, re-using a created container directly using the testcontainer's framework is impossible; so to accomplish the same thing utilizing testcontainer's framework we can configure the GenericContainer with a fixed container name. This fixed container name then allows other test packages within an application to reference the already created container minimizing resource consumption and repeated start up cost.

Currently in applications with lots of tests/slow running tests this singleton couchbase container starts up and runs just fine when tests attempt to create their own container via Run but once the Admin user has been enabled by the first test, all subsequent tests fail with "init cluster: context deadline exceeded" because the http requests are failing with 401.

Related Issues

• [Enhancement]: Couchbase container context deadline exceeded when reused #3049

Follow-ups

It is likely that other implementations of testcontainers for other common images will have a similar issue when the container is reused.

[netlify]

✅ Deploy Preview for testcontainers-go ready!

Name	Link
🔨 Latest commit	aba0a34
🔍 Latest deploy log	https://app.netlify.com/projects/testcontainers-go/deploys/68397abf5c697c00084e2d45
😎 Deploy Preview	https://deploy-preview-3048--testcontainers-go.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.

[eddumelendez]

We had a similar issue in Testcontainers for Java and was fixed by skipping the configuration when reuse is enabled testcontainers/testcontainers-java#9957

[waroir20]

We had a similar issue in Testcontainers for Java and was fixed by skipping the configuration when reuse is enabled testcontainers/testcontainers-java#9957

How would you handle the issue of not knowing which of the calls would be the one to be the first to cause the initialization, as well as returning the container too early in ones where is was skipped (i.e. before the configuration occurred)?

[mdelapenya]

LGTM, thanks!

[mdelapenya]

@waroir20 I've already approved this PR, although I'd like you to take a look at the current initCluster function, which is executed after the container is started. Do you think it could be converted into parts of the life cycle hooks of the container? Then it would be easier to skip parts of the life cycle hooks when reuse is active, and possible change this behaviour:

https://github.com/testcontainers/testcontainers-go/blob/main/docker.go#L1367-L1382

	// If a container was stopped programmatically, we want to ensure the container
	// is running again, but only if it is not paused, as it's not possible to start
	// a paused container. The Docker Engine returns the "cannot start a paused container,
	// try unpause instead" error.
	switch c.State {
	case "running":
		// cannot re-start a running container, but we still need
		// to call the startup hooks.
	case "paused":
		// TODO: we should unpause the container here.
		return nil, fmt.Errorf("cannot start a paused container: %w", errors.ErrUnsupported)
	default:
		if err := dc.Start(ctx); err != nil {
			return dc, fmt.Errorf("start container %s in state %s: %w", req.Name, c.State, err)
		}
	}

Tell me what you think, and we could maybe merge this as is, and work on the refactor as a follow-up

Thanks!

[mdelapenya]

Merged, thanks for your work here! Just in case you have time and are interested, I'd like you to check my comment here 🙏

Cheers!