feat: Add KAFKA mocking

[SebastienDegodez]

Pull Request

Proposed Changes

The goal of this enhancement is to add KAFKA support to the testcontainers module.

For the moment, AsynchronousAPI mocking are not supported. This feature would require an additionnal container microcks-async-minion.

Readiness Checklist

Author/Contributor

• If documentation is needed for this change, has that been included in this pull request
• run dotnet test and ensure you have test coverage for the lines you are introducing
• run dotnet husky run and fix any issues that you have introduced

Reviewer

• Label as either feature, fix, documentation, enhancement, maintenance or breaking

[SebastienDegodez]

In JAVA, @lbroudoux introduce a notion MicrocksContainersEnsemble.
An ensemble allows you to configure and controle the multiple containers with one line.
It's a good choice to increase a developper experience.

But this approach use testcontainer lifecycle Startable, i don't see the similar usage in .NET.

[lbroudoux]

In JAVA, @lbroudoux introduce a notion MicrocksContainersEnsemble. An ensemble allows you to configure and controle the multiple containers with one line. It's a good choice to increase a developper experience.

But this approach use testcontainer lifecycle Startable, i don't see the similar usage in .NET.

Yes, this approach was quite convenient in Java (and necessary to integrate with frameworks like Spring that can manage the testcontainers lifecycle). However it is typically not available in other Testcontainers bindings like Node or Go.

I think it's nice to keep this notion of MicrocksContainersEnsemble being different from a single MicrocksContainer and allowing reuse of this one + wrapping the other needed container. Also, I think it's important to stick with the idioms of each language/platform and thus the MicrocksContainersEnsemble would have its own ContainerBuilder while implementing DockerContainer even if - behind the scenes - it manages multiple containers. What do you think?

[SebastienDegodez]

Issue KafkaContainer (.NET) testcontainers/testcontainers-dotnet#1314

[SebastienDegodez]

Contribution to add network on Kafka: testcontainers/testcontainers-dotnet#1316

[lbroudoux]

Contribution to add network on Kafka: testcontainers/testcontainers-dotnet#1316

Hey @SebastienDegodez! I had the same issue with Kafka module on testcontainers Go unfortunately...

[SebastienDegodez]

Contribution to add network on Kafka: testcontainers/testcontainers-dotnet#1316

Hey @SebastienDegodez! I had the same issue with Kafka module on testcontainers Go unfortunately...

Hey, I have develop the feature in the train this morning. For the moment, i replace the kafka_listener, protocole and advertised (in startupCallback).

[SebastienDegodez]

Hello @lbroudoux , "sonar.token is invalid"

I don't understand. We have lost a secret ?

[lbroudoux]

Hello @lbroudoux , "sonar.token is invalid"

I don't understand. We have lost a secret ?

I've checked and SONAR_TOKEN is still declared in configuration.

It is used here: https://github.com/microcks/microcks-testcontainers-dotnet/blob/main/.github/workflows/steps.dotnet-build-test.yml#L67

I think the issue you get is because the build is happening on your own branch (your fork) and not on the Microcks one. In that case, the secret we defined is not available. Maybe we should add an additional condition to prevent trying to launch the Sonar analysis? Will check this.

[SebastienDegodez]

Hello @lbroudoux , "sonar.token is invalid"

I don't understand. We have lost a secret ?

I've checked and SONAR_TOKEN is still declared in configuration.

It is used here: https://github.com/microcks/microcks-testcontainers-dotnet/blob/main/.github/workflows/steps.dotnet-build-test.yml#L67

I think the issue you get is because the build is happening on your own branch (your fork) and not on the Microcks one. In that case, the secret we defined is not available. Maybe we should add an additional condition to prevent trying to launch the Sonar analysis? Will check this.

I can have a condition but to follow Sonar for all pr, it's not practical. For the future, do you think it is possible to add me the right to create and push only the branch in feature/* without risk for other repo or the main branch (or another strategy) ?