Github user mccheah commented on a diff in the pull request:
https://github.com/apache/spark/pull/19468#discussion_r146428556
--- Diff: pom.xml ---
@@ -2649,6 +2649,13 @@
</profile>
<profile>
+ <id>kubernetes</id>
+ <modules>
+ <module>resource-managers/kubernetes/core</module>
--- End diff --
It's not absolutely necessary to have integration tests in a specific
separate module. However, there are some nice organizational benefits we can
get. For example, integration tests in the same module as the core code will
need a specific package namespace that is omitted from the `test` phase and
only executed in the `integrationTest` phase. Having a separate module means
that the integration test pom can just make the `test` phase a no-op and
integrationTest runs all tests in the `test` folder. (I don't know if Maven has
a concept of a difference between `src/test/scala` and
`src/integrationTest/scala`, which would help a lot.)
It's also IMO easier to read the `pom.xml` of the integration test
separately from the `pom.xml` of the Kubernetes core implementation. FWIW this
is what we have in the integration test POM at the moment:
https://github.com/apache-spark-on-k8s/spark/blob/branch-2.2-kubernetes/resource-managers/kubernetes/integration-tests/pom.xml.
(The minikube related things are going away with
https://github.com/apache-spark-on-k8s/spark/pull/521).
> And that's assuming that you really don't want to run them during unit
tests.
We definitely don't want to run these during unit tests - they are
relatively expensive, require building Docker images, and require Minikube to
be pre-installed on the given machine. Having them in at least the separate
integration test phase makes these differences clear.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
