Seems so but is not. Most of beam tests assume they are alone in their vm
when executing for a bunch of reason, if not the case a lot of side effects
can happen (backend state, local cache drop, , uncontrolled resources
and failure due to the GBKTest which creates 100M keys etc...) so you
It seems that the test probably depends on some details of Maven or our
Maven configuration. If so, that's a problem with the test. It should be
able to succeed in any build system, or as a standalone JUnit main built
from the suite, etc.
Kenn
On Thu, Apr 12, 2018 at 9:27 AM Romain Manni-Bucau
on maven it is quite reliable, ran it > 10 times without any failure.
I suspect (but didnt check by lack of time) gradle parallelism is
different somehow and can lead to some flackyness here.
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
2018-04-12 18:20
It looks like the precommit failure [1] is for a new test that was added.
Have you debugged the test to ensure it's not flaky?
[1]
Hi guys,
did the gradle track changed the way test execution was done?
This PR https://github.com/apache/beam/pull/4965 works very well with
maven and sometimes doesn't pass with gradle. Think we should keep the
previous setup which was globally reliable (I'm not speaking of tests
which are not
