> On Jul 1, 2020, at 12:16 PM, Udo Kohlmeyer wrote:
>
> To think a little more left field, with our continued investment in K8’s,
> maybe we can look into that area?
> Run tests in parallel using K8’s?
It’s an interesting idea but even more complicated than the docker solution.
Since k8s
To think a little more left field, with our continued investment in K8’s, maybe
we can look into that area?
Run tests in parallel using K8’s?
But I am also supportive of fixing the tests that we can run them in parallel
without the extra container scaffolding.
—Udo
On Jul 1, 2020, 11:38 AM
> On Jul 1, 2020, at 11:14 AM, Kirk Lund wrote:
>
> I'm not a big fan of forking the Docker plugin and making it a new Geode
> submodule. This approach kind of flies in the face of the intentions of OSS
> in general. For example, we want folks contributing to Apache Geode rather
> than
I'm not a big fan of forking the Docker plugin and making it a new Geode
submodule. This approach kind of flies in the face of the intentions of OSS
in general. For example, we want folks contributing to Apache Geode rather
than forking Geode to create their own new project while never giving back
0 12:28 PM
To: dev@geode.apache.org
Subject: Re: Us vs Docker vs Gradle vs JUnit
I would vote for fixing the tests to use gradle's normal forking. If we are
going to invest time and effort, let's invest in an option that can reduce our
dependencies
___
> On Jun 30, 2020, at 2:10 PM, Anthony Baker wrote:
>
> When evaluating technical alternatives I think it’s helpful to look at data.
> Has anyone recently tried to run the entire dunit test suite in parallel w/o
> docker? How many tests need to be changed? IIRC, there would be non-trivial
oint in the future.
>
> From: Jinmei Liao
> Sent: Tuesday, June 30, 2020 12:28 PM
> To: dev@geode.apache.org
> Subject: Re: Us vs Docker vs Gradle vs JUnit
>
> I would vote for fixing the tests to use gradle's normal forking. If we are
> going to invest
> On Jun 30, 2020, at 12:28 PM, Jinmei Liao wrote:
>
> I would vote for fixing the tests to use gradle's normal forking. If we are
> going to invest time and effort, let's invest in an option that can reduce
> our dependencies
I agree wholeheartedly!
Dale
.
From: Jinmei Liao
Sent: Tuesday, June 30, 2020 12:28 PM
To: dev@geode.apache.org
Subject: Re: Us vs Docker vs Gradle vs JUnit
I would vote for fixing the tests to use gradle's normal forking. If we are
going to invest time and effort, let's invest in an option that can reduce our
: Us vs Docker vs Gradle vs JUnit
All,
We are in a bit of a pickle. As you recall from a few years back in an effort
to both stabilize and parallelize integration, distributed and other
integration/system like test we use Docker. Many of the tests reused the same
ports for services which cause
All,
We are in a bit of a pickle. As you recall from a few years back in an effort
to both stabilize and parallelize integration, distributed and other
integration/system like test we use Docker. Many of the tests reused the same
ports for services which cause them to fail or interact with
11 matches
Mail list logo
