Harden MinIO readiness and benchmark setup
Replaced a first-log-line MinIO wait with an HTTP health check and updated the CLI benchmark compose stack and documentation to use the repository's digest-pinned MinIO image.
apache/seatunnel · #12478
Test-infrastructure reliability fix
S3 integration tests now wait for MinIO's actual readiness endpoint, while the local benchmark stack uses available, digest-pinned images.
Problem
MinIO emits its first log line before it serves S3 requests, so S3FileWithFilterIT could race startup and fail when setup immediately called the bucket API. The local CLI benchmark also referenced MinIO images that rejected anonymous pulls.
Approach
Uses Testcontainers' bounded /minio/health/ready probe before S3 initialization, and aligns the benchmark's server and client services with the digest-pinned image already adopted by SeaTunnel's E2E tests.
Impact and scope
- Replaces a timing-sensitive log signal with a condition-based service-readiness check on every S3FileWithFilterIT run.
- Restores fresh local benchmark environments without reopening the repository's already-settled MinIO image choice.
- Produces a clearer bounded container-startup failure instead of allowing an early S3 request to fail downstream.
- Touches E2E and local benchmark infrastructure only; no production code, public API, connector option, or release artifact changed.
Validation
- The S3FileWithFilterIT class passed all three tests under the new readiness strategy on both Java 8 and Java 11 CI jobs.
- The final diff was reduced to three targeted files after syncing with the development branch and removing changes already solved upstream.
- All eight hosted checks passed, and the final upstream re-review approved the authored change with no blockers.