I agree these tests should be manual for now but should be run somehow before a release to make sure things are working right?
For the other issue: https://issues.apache.org/jira/browse/SPARK-25835 . On Thu, Oct 25, 2018 at 6:29 PM, Stavros Kontopoulos < stavros.kontopou...@lightbend.com> wrote: > I will open a jira for the profile propagation issue and have a look to > fix it. > > Stavros > > On Thu, Oct 25, 2018 at 6:16 PM, Erik Erlandson <eerla...@redhat.com> > wrote: > >> >> I would be comfortable making the integration testing manual for now. A >> JIRA for ironing out how to make it reliable for automatic as a goal for >> 3.0 seems like a good idea. >> >> On Thu, Oct 25, 2018 at 8:11 AM Sean Owen <sro...@gmail.com> wrote: >> >>> 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 >>> >>> > >
