After watching the recording posted by Alexander for the June geode community
meeting, I wondered if the cleanest thing to do is to ensure that "server2" (in
the same pod with the Istio/Envoy sidecar that terminates) is also terminated.
I know that in our in-house testing, we use a sidecar with
I think the basic problem is that we have too much tech debt in the form of
dunit tests. We are proposing all of these "workarounds" to avoid dealing with
the core problem.
On 6/8/21, 12:09 PM, "Dan Smith" wrote:
Would it be possible to just split that test up into multiple classes? It
s
Would it be possible to just split that test up into multiple classes? It
sounds like the issue is that there is so many flaky tests in that class that
you can't fix them all in one PR, which might indicate it's too big.
If we can't get StressNewTest to pass - that means our builds are failing m
Maybe we can find a way to relax the requirement, or to allow addressing
specific situations like the tangle you find yourself in.
Removing the requirement altogether feels overly broad. I fear it would allow
us to quietly disregard all intermittent test failures, and I think we already
quietly
I think repeated tests shouldn’t be a blocker to merging for the reasons
outlined below. A committer that is a good steward for the project should be
allowed to make the judgement call when merging a PR. We have placed too many
rigid processes in place that eliminated the good judgement of commi
Thanks Kirk for tackling some of our flakiest tests! I agree, we don't want to
discourage anyone interested in paying down tech debt.
The Geode community has spoken clearly against bypassing or weakening required
PR checks, so relaxing requirements in general might be a tough sell, but I'm
cur
I understand the challenge, but I disagree. It is only through requirement that
we keep new flakey tests out. While I don't think one should have to fix all
the flaky tests to get their unrelated change in, I think it serves a purpose.
IMHO, the problems that you are seeing are indications that
Our requirement for stress-new-test-openjdk11 to pass before allowing merge
doesn't really work as intended for fixing distributed tests that contain
multiple flaky test methods. In fact, I think it causes contributors to
avoid tackling flaky tests.
I've been working on GEODE-9103: CI Failure:
Put