FenjuFu commented on issue #11638: URL: https://github.com/apache/seatunnel/issues/11638#issuecomment-5177505056
I audited current main for literal yrantlucifer/ references. The actual Docker image dependencies are concentrated in seatunnel-e2e-common (the other search hits in file connector tests/docs are test paths such as ame=tyrantlucifer, not image names): - Spark: yrantlucifer/spark:2.4.6 (Spark2Container) and yrantlucifer/spark:3.3.0 (Spark3Container). - Flink: yrantlucifer/flink:1.13.6-scala_2.11_hadoop27, 1.14.6-scala_2.11_hadoop27, 1.15.3-scala_2.12_hadoop27, 1.16.0-scala_2.12_hadoop27, 1.17.2-scala_2.12_hadoop27, 1.18.0-scala_2.12_hadoop27, and 1.20.1-scala_2.12_hadoop27 in the corresponding Flink*Container classes. That means the directly affected execution paths are the shared Spark 2/3 and Flink 1.13-1.18/1.20 E2E environments, rather than individual file connector modules. There is an existing architecture-selection precedent in connector-cdc-oracle-e2e (AbstractOracleCDCIT#getImage, checking os.arch == aarch64) and a multi-arch image precedent noted in connector-cdc-postgres-e2e. For an incremental first slice, I suggest publishing the Dockerfiles/build metadata in-repo and rebuilding the two Spark tags as linux/amd64,linux/arm64, since that covers both shared Spark environments with two images. If an Apache-managed registry/namespace is available, I can prepare the container-class updates and buildx workflow against the agreed image names; otherwise changing Java references before a durable image destination exists would leave the tests unusable. Please confirm the preferred registry path and where these Dockerfiles should live, and I'll take that slice. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
