deps(java): bump zeebe-test-container from 0.33.0 to 1.0.0

[dependabot]

Bumps zeebe-test-container from 0.33.0 to 1.0.0.

Release notes

Sourced from zeebe-test-container's releases.

1.0.0

Breaking changes

The 1.0.0 release marks a major breaking change. We decided to step away from the high level configuration API, which proved brittle and too tightly coupled with Zeebe versions. Instead, the focus was on minimizing API surface to ease the burden of maintenance, while maintaining a good feature set. This means that if you are currently using a release pre 1.0.0, please carefully read the updated documentation as most of the API has changed.

Notable changes

Users are expected to configure their Zeebe containers via environment variables and configuration files. The zeebe-test-container module now simply provides the following:

• Three containers for different use cases: broker with embedded gateway (ZeebeContainer), broker without embedded gateway (ZeebeBrokerContainer), and standalone gateway (ZeebeGatewayContainer). If unsure, you probably want ZeebeContainer.
• Very little default configuration is applied on top of existing Zeebe defaults: see each container's Javadoc for more, but it's mostly network configuration around the host/advertisedHost configuration to allow for clustering over an SDN.
• The broker wait strategy has been dropped, and is now only a combination of waiting for the host ports to be ready, and the broker ready check to return a 204.
• A new gateway strategy was introduced which waits until the topology is "complete". A complete topology is one where all partitions in the cluster have a leader - as the gateway does not know this beforehand, it's important that the user specify this when building the container. This strategy ensures that when a gateway container is started, it is ready to receive client requests and there are brokers behind to process them.

Upgrading

zeebe-test-container 1.0.0 is only tested against Zeebe 0.23.x and later versions. This is primarily due to new features introduced in 0.23.x (e.g. new configuration system). It may work with previous versions, but don't expected patches or support for them.

The main effort in upgrading will be that you now have to specify your configuration explicitly instead of using the high level API. Please refer to the Zeebe documentation on how to do this.

Another thing that might need to be changed is regarding the wait strategies - if you were configuring multiple partitions for a broker, or had a clustered setup, the gateway strategy will need to be properly updated to know about all these partitions. Refer to the README or Javadoc for more.

What's Changed

• feat: simplify API and update Zeebe (#69) @npepinpe

📦 Dependency updates

• chore(deps): bump version.zeebe from 0.24.1 to 0.24.2 (#76) @dependabot-preview
• chore(deps-dev): bump version.mockito from 2.21.0 to 3.5.10 (#85) @dependabot-preview
• chore(deps-dev): bump assertj-core from 3.17.1 to 3.17.2 (#86) @dependabot-preview
• chore(deps-dev): bump assertj-core from 3.17.0 to 3.17.1 (#83) @dependabot-preview
• chore(deps-dev): bump assertj-core from 3.16.1 to 3.17.0 (#80) @dependabot-preview
• chore(deps): bump version.zeebe from 0.22.1 to 0.23.3 (#68) @dependabot-preview

Contributors

@dependabot-preview, @dependabot-preview[bot], @npepinpe, @zeebe-bors[bot] and camunda-jenkins

Commits

• bdeb2b0 [maven-release-plugin] prepare release 1.0.0
• 98a9b25 Merge #76
• b44be51 Merge #85
• fd5ca2d Merge pull request #86 from zeebe-io/dependabot/maven/org.assertj-assertj-cor...
• 7b5bd0c chore(deps-dev): bump assertj-core from 3.17.1 to 3.17.2
• 614455a chore(deps-dev): bump version.mockito from 2.21.0 to 3.5.10
• f495987 Merge pull request #83 from zeebe-io/dependabot/maven/org.assertj-assertj-cor...
• 5aab042 chore(deps-dev): bump assertj-core from 3.17.0 to 3.17.1
• d18b5d2 Merge pull request #80 from zeebe-io/dependabot/maven/org.assertj-assertj-cor...
• 9615bad chore(deps-dev): bump assertj-core from 3.16.1 to 3.17.0
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #71.