Yes, I agree, and perhaps you are best placed to do that for 2.4.0 RC5 :) On Thu, Oct 25, 2018 at 10:41 AM Stavros Kontopoulos <stavros.kontopou...@lightbend.com> wrote: > > 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 >>>> >> >> >
--------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
