DanielLeens commented on PR #11791: URL: https://github.com/apache/seatunnel/pull/11791#issuecomment-5292329385
Thanks for flagging this, @nzw921rx -- validating on your forked dev branch first is a good way to close the one residual gap from my last review (carryover Issue 2): because this PR only touches `.github/workflows/**` and `tools/**`, the `changes` job never set `api=true`/`engine=true` on any of this PR's own runs, so `all-connectors-it-*`, `iceberg-connector-it`, `hbase-connector-it`, and `updated-modules-integration-test-part-*` were all skipped every time -- the only evidence so far is offline replay of the sharding function, not a live run of the actual job topology. Two concrete things worth confirming on that fork run before merging: 1. All 7 `all-connectors-it-N` shards fire and each finishes inside its 150-minute budget (120 for `iceberg-connector-it`) -- the balanced hash assignment is the part that changed most. 2. A push that touches only one connector module still resolves to the right shard through `updated-modules-integration-test-part-*`, since that exercises the separate `get_sub_update_it_modules` path rather than the full-matrix one. On the merge risk itself: since the diff is CI-orchestration only (no production Java/Scala touched), the worst case if something is off is a misfiring job or a shard timing out on dev, not a runtime regression for users -- so your fork-verification step is mainly about avoiding a noisy dev run rather than an application-level risk. Once that's green I don't have anything else blocking from my side; my last review already concluded ready-to-merge with only Issue 4 (the edge-agent-e2e exclusion asymmetry) left as a non-blocking follow-up. -- 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]
