Forking this thread. Because we'll have another RC, we could possibly address these two issues. Only if we have a reliable change of course.
Is it easy enough to propagate the -Pscala-2.12 profile? can't hurt. And is it reasonable to essentially 'disable' kubernetes/integration-tests by removing it from the kubernetes profile? it doesn't mean it goes away, just means it's run manually, not automatically. Is that actually how it's meant to be used anyway? in the short term? given the discussion around its requirements and minikube and all that? (Actually, this would also 'solve' the Scala 2.12 build problem too) On Tue, Oct 23, 2018 at 2:45 PM Sean Owen <sro...@gmail.com> wrote: > > To be clear I'm currently +1 on this release, with much commentary. > > OK, the explanation for kubernetes tests makes sense. Yes I think we need to > propagate the scala-2.12 build profile to make it work. Go for it, if you > have a lead on what the change is. > This doesn't block the release as it's an issue for tests, and only affects > 2.12. However if we had a clean fix for this and there were another RC, I'd > include it. > > Dongjoon has a good point about the spark-kubernetes-integration-tests > artifact. That doesn't sound like it should be published in this way, though, > of course, we publish the test artifacts from every module already. This is > only a bit odd in being a non-test artifact meant for testing. But it's > special testing! So I also don't think that needs to block a release. > > This happens because the integration tests module is enabled with the > 'kubernetes' profile too, and also this output is copied into the release > tarball at kubernetes/integration-tests/tests. Do we need that in a binary > release? > > If these integration tests are meant to be run ad hoc, manually, not part of > a normal test cycle, then I think we can just not enable it with > -Pkubernetes. If it is meant to run every time, then it sounds like we need a > little extra work shown in recent PRs to make that easier, but then, this > test code should just be the 'test' artifact parts of the kubernetes module, > no? --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
