We've started to have a mix of Debezium container image / Connect versions in the test suite, so as to support recently added Connect API calls. This created some challenges when the workers of different KC versions formed a cluster when keeping the Docker container(s) running for the duration of the entire test suite.
We could avoid this kind of issue, and also make sure any "emulated" kcctl features (where we fall back to multiple API calls on older Connect versions) are tested thoroughly, by setting up matrix testing on CI. We would:
- Work against only a single Connect version in the test code (defaulting to the latest one we support)
- Add an annotation like
@SkipIfConnectVersionIsOlderThan("3.5") for excluding tests for new features when testing against older versions
- Make the version to test against configurable via an env var
- Configure a matrix test job on GH Actions for testing against all the versions we want to support (not sure what would make sense, perhaps all 3.x minors and latest 2.x minor? Or is this too much?)
@C0urante, curious what you think?
We've started to have a mix of Debezium container image / Connect versions in the test suite, so as to support recently added Connect API calls. This created some challenges when the workers of different KC versions formed a cluster when keeping the Docker container(s) running for the duration of the entire test suite.
We could avoid this kind of issue, and also make sure any "emulated" kcctl features (where we fall back to multiple API calls on older Connect versions) are tested thoroughly, by setting up matrix testing on CI. We would:
@SkipIfConnectVersionIsOlderThan("3.5")for excluding tests for new features when testing against older versions@C0urante, curious what you think?