kz930 opened a new pull request, #7207:
URL: https://github.com/apache/texera/pull/7207

   ### What changes were proposed in this PR?
   
   The `amber` job runs the `WorkflowOperator` module's test suite and installs 
no Python packages. The runner's interpreter is there — 
`PythonCodeRawInvalidTextSpec` uses it for a stdlib-only `py_compile` check — 
but pandas and plotly are not importable, so a test that *executes* an 
operator's generated template rather than only compiling it fails its 
dependency probe and cancels. A cancellation is neither a pass nor a failure, 
so the suite still reports "All tests passed" and the missing coverage leaves 
no trace in the build.
   
   This gives `WorkflowOperator` the split `amber` already has:
   
   1. An `IntegrationTest` tag under `common/workflow-operator/src/test`. 
`amber`'s tag cannot be reused: it lives in `amber/src/test/integration`, and 
`amber` depends on `WorkflowOperator`, not the other way around.
   2. A `Test / testOptions` filter in `common/workflow-operator/build.sbt` 
reading the same `AMBER_TEST_FILTER`. The `amber` job already sets that 
variable on the step that invokes `WorkflowOperator/jacoco`, so that job needs 
no change for the exclusion to take effect.
   3. `"WorkflowOperator/test"` added to the `amber-integration` invocation, 
which already runs `integration-only` with `amber/requirements.txt` and 
`amber/operator-requirements.txt` installed (pandas 2.2.3, plotly 5.24.1).
   
   With the selection logic now wanted in two modules, it moves to 
`project/TestFilters.scala` next to the build's other shared sbt helpers 
(`AddMetaInfLicenseFiles.scala`, `JdkOptions.scala`), and each module passes 
its own env var, tag, and any extra ScalaTest arguments.
   
   `PythonCodeRawInvalidTextSpec` gains a tagged case asserting that pandas and 
plotly import in the interpreter it already resolves — `py_compile` only parses 
the emitted code, while running it needs the packages it imports. Being the 
first user of the tag it also exercises the routing, and it turns a missing 
install in `amber-integration` into a failure rather than the silent 
cancellation described above. Elsewhere a bare interpreter is a local-setup 
fact, so it cancels instead.
   
   ### Any related issues, documentation, discussions?
   
   Fixes #7186. The silent cancellation was found while reviewing #7149, whose 
runtime test is the case that cancels today; tagging it is a one-line follow-up 
once this is in.
   
   ### How was this PR tested?
   
   Behavior of the extraction is unchanged: `show Test/testOptions` for both 
modules under all three env states produces byte-identical arguments to the 
previous inline code — `-l <tag>` on `skip-integration`, `-n <tag>` on 
`integration-only`, nothing when unset.
   
   The new case was exercised in all four states it can be in, running 
`WorkflowOperator/testOnly *PythonCodeRawInvalidTextSpec`: with the packages 
present it passes under `integration-only` (1 test selected); under 
`skip-integration` it is excluded while the spec's two existing tests still run 
(2 tests); pointed at a bare interpreter it fails under `integration-only` and 
cancels with no filter set.
   
   `sbt scalafmtCheckAll` is clean, and `WorkflowOperator`'s `Compile` and 
`Test` scalafix checks pass.
   
   ### Was this PR authored or co-authored using generative AI tooling?
   
   Generated-by: Claude Code (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]

Reply via email to