DanielLeens commented on PR #11545: URL: https://github.com/apache/seatunnel/pull/11545#issuecomment-6051399349
Thanks @SEZ9. Against head `74ac922d6`: **CI for `74ac922d6`, as of now.** Attempt 1 finished with 95 of 96 jobs green, including `Dependency licenses` and all four `unit-test` legs. The one non-green job was `all-connectors-it-6 (11)`: cancelled at its 2h30m job timeout while stuck in `FlussSourceIT` (no module-access errors in its log). I re-ran only that job; attempt 2 is in progress and the other 95 stay green (86 success, 9 skipped, 1 running). I will post the final result when it lands. I am not calling the run green until it does. **Description (done, verified identical after the edit).** It now says the launcher scripts are the source of truth and that the flags in `config/jvm_*_options` are a convenience, so the launcher injection must not be removed on the assumption that the config files suffice. It also lists, per flag, what evidence exists: only `java.net` has a captured failing trace; `java.nio` is additionally required by Arrow in `connector-lance` (seen failing without it on JDK 17); the Hazelcast-attributed ones and the krb5 export are unbisected and marked as candidates to trim, not authoritative. That is your option (b). The same wording for the config-file comments needs a push, which I am holding until the attempt-2 job finishes, because a push cancels the running job; it will go in with the next push. **F6 / F8.** Agreed it is a temporary state. The `backend.yml` comment links apache/seatunnel#12655, and that issue already is the follow-up you ask for: its suggested change is to make `connector-lance` inherit the root argLine and then remove the repeated flags from `SUREFIRE_JVM_ARGS`, after which CI exercises the pom property on a plain JDK 11/17 lane. **F4 / F7.** The pin is in `upgrade_compatibility.yml`: a single `actions/setup-java@v4` step with `java-version: "11"` (lines 52-59, no matrix), and that one JDK runs both the tooling and the old 2.3.13 cluster. I cannot confirm that the old cluster starts cleanly without the jgss export: that workflow only runs on `workflow_dispatch` and the nightly cron on the main repo, it is not registered on my fork (so I cannot dispatch it there), and no run of it exists for this change. My reasoning that it should start is from JDK behaviour (illegal reflective access is permitted by default through JDK 15), not from a run. I would leave F4/F7 open until that workflow runs, or until a maintainer dispatches it on this branch. -- 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]
