weiqingy opened a new pull request, #1007: URL: https://github.com/apache/flink-agents/pull/1007
Linked issue: #1006 ### Purpose of change `tools/ut.sh` told the reader that omitting `-f` tests every supported Flink version. It tests one, and on the Java unit-test path the selected version is not used at all. Because `DEFAULT_FLINK_VERSION` was pinned to `2.2` while the root pom carries `2.3.0`, a bare `./tools/ut.sh` tested Java on 2.3.0 and Python on 2.2.x in the same command. The first commit derives the default from `<flink.version>` in the root pom instead of pinning it, so both lanes land on the same version and the value cannot drift again. That drift is the root cause rather than an accident: `tools/update_flink_version.sh` rewrites poms only and never touches this script, so the pinned literal fell a minor line behind. The derived value is validated to be shaped `x.y` before use, because it flows unvalidated into `dist/flink-<v>` paths, `-Pflink-<v>` profile names and the `apache-flink~=<v>.0` requirement. Reading the property with `sed` follows `tools/update_flink_version.sh`, which already reads the same property the same way. The second commit warns when `-f` cannot affect what was selected. `./tools/ut.sh -j -f 1.20` previously accepted the flag and then tested exactly what it would have anyway. A warning was chosen over rejecting the flag, since rejecting it turns a currently-working command into a failing one. The help text now states the derived default and the flag's real scope. One option in the issue is deliberately not taken. Making the default iterate every supported version is not implementable today: `runtime` fails `test-compile` at 1.20 with 5 errors in `RescalingTest.java`, which imports `org.apache.flink.streaming.api.functions.sink.legacy` and `...source.legacy`, packages that exist only in Flink 2.x. It would also multiply every job that runs the Java unit tests by roughly five, to duplicate coverage the `java_it_tests` matrix already provides across all five versions. ### Tests New `tools/test/unit/ut_sh_version_default.bats` (8 cases) and `tools/test/unit/ut_sh_flink_flag_scope.bats` (6 cases), in the existing bats harness that CI already runs. Both use the subprocess and shim patterns from `tools/test/integration/help.bats` and `dry_run.bats`; neither sources `ut.sh`, which has no run guard. The version cases cover the derived default, that it follows a changed pom rather than coincidentally matching today's value, whitespace-padded XML, and the three malformed shapes that must be fatal. The scope cases pin the firing condition rather than just the message, so an over-broad or under-broad condition fails. Full harness: 198 ok / 1 not ok. The single failure is pre-existing and unrelated, in `verify_example_job.bats` via `e2e-test/test-scripts/test_submit_examples_to_flink.sh:362` (`remaining_pids[@]: unbound variable`); it reproduces identically on unmodified `main`. `./tools/ut.sh -p` was run on the new default: 825 passed, 13 skipped, exit 0, against `apache-flink 2.3.0` confirmed from the environment rather than the log. Note one behavior change: the Python unit-test jobs in `ci.yml` and `build_wheel.yml` now install `apache-flink~=2.3.0` rather than `~=2.2.0`. PyFlink 2.3.0 is published and is the current latest on PyPI. Both integration matrices pass `-e -f` explicitly and are unaffected, and none of the six workflow invocations emits the new warning. Not covered: the `pip` fallback branch of `ut.sh -p` was not exercised on the new default, only the `uv` branch that CI uses. ### API No public API change. The observable change is to the script's CLI behavior and help text, described above. ### Documentation - [ ] `doc-needed` - [x] `doc-not-needed` - [ ] `doc-included` Every inaccurate claim was in the script's own help text, which this PR corrects. No file under `docs/` references `tools/ut.sh`. ### Was this patch authored or co-authored using generative AI tooling? - [x] Yes - [ ] No Generated-by: Claude Code 2.1.229 (Claude Opus 5) -- 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]
