We could keep it in one JVM but make it optional for merging the PR?
On Mon, Dec 30, 2019 at 10:06 AM Jinmei Liao wrote:
> Having the stressTest reuse the JVMs is close to running the tests in my
> IDEA repeatedly for N times or running a package of tests together in my
> IDEA. There was a time
Having the stressTest reuse the JVMs is close to running the tests in my
IDEA repeatedly for N times or running a package of tests together in my
IDEA. There was a time that I couldn't run a group of tests together in my
IDEA until I had to fix the problem for the stressTest. Keeping them
running i
Regarding the StressTest job - how about we switch that have a new JVM for
each test? That's how DistributedTest and IntegrationTest normally run. We
let StressTest reuse the JVMs because it would be faster and find problems
related to static state left behind, but I think in practice people are
fi
Here's my take on stresstest. It's currently providing two purposes:
1) Prevents addition of new flaky tests
Some new flakiness does slip through. I can write a new test that passes
50-100 times consistently and thus gets by stresstest, but then fails once
or twice in CI or dunitrunner when I run
@Jacob Barrett @Robert Houghton I
have an interest in expediting docs-only PRs and would be interested in
participating in a break-out discussion (or at least reviewing the
conclusions).
On Mon, Dec 30, 2019 at 9:15 AM Robert Houghton
wrote:
> @Jacob Barrett I have some ideas on this. Want to
@Jacob Barrett I have some ideas on this. Want to
look at in on Thursday with me?
On Sat, Dec 28, 2019 at 5:28 AM Jacob Barrett wrote:
> Let’s find a way to get the ci, docs, and other directories not effected
> by tests out of this testing hold.
>
> > On Dec 27, 2019, at 3:23 PM, Nabarun Nag
I feel that we should keep it but that we need to look into what's
causing the frustration with the stresstest job. That seems to be the
thing causing the most grief. People make a small change to some test,
such as changing an import statement, and then find that it fails in
stresstest.
I
Let’s find a way to get the ci, docs, and other directories not effected by
tests out of this testing hold.
> On Dec 27, 2019, at 3:23 PM, Nabarun Nag wrote:
>
> Please maintain the branch protection rules.
> Waiting for reviews and Unit tests to pass does not stifle productivity,
> but prev
Please maintain the branch protection rules.
Waiting for reviews and Unit tests to pass does not stifle productivity,
but prevents us from making mistakes that are detrimental to the entire
community. If I am not mistaken, we still have pushed code which broke
builds and regressions. I would sugges
I would like to keep as is...In my opinion this should not been seen as
policing; rather a concerted effort towards keeping the code stable. And
way to isolate the problem sooner than later (after merging of multiple
PRs, which will make it harder). Yes, I agree it may be annoying to sit on
code ch
Just to add more flavor to my previous response... I currently have a PR
open that modified a method signature that touched a few WAN tests. It was
a simple change, removing an unused parameter. StressNewTest failed and I
had to spend another day figuring out 10 or so different failures. A waste
I feel the frustration at times, but I do also think the ci/pipelines are
improving, breaking less often. I'm ok with the way things are for the
moment
On Fri, Dec 27, 2019 at 1:47 PM Owen Nichols wrote:
> In October we agreed to require at least 1 reviewer and 4 passing PR
> checks before a PR
In October we agreed to require at least 1 reviewer and 4 passing PR checks
before a PR can be merged. Now that we’re tried it for a few months, do we
like it?
I saw some strong opinions on the dev list recently:
> Changes to the infrastructure to flat out prevent things that should be self
>
13 matches
Mail list logo
