The jobs just launch heavy lifter linux instances to run Gradle so this is just
a pretty good sized plain old linux host. Sounds like maybe there are too many
integration tests running in parallel eating up more memory than before. This
may cause the virtual memory manager to panic and start kil
I have multiple PRs submitted from multiple branches, all rebased etc. They
all fail and the gradle process dies. The failure message (when there is
one) always says the same thing...
Some sort of environment issue is causing DistributedTestOpenJDK11 to fail
[1] and the Gradle daemon to die (on ev
I wonder if the auto merge creates something funky. Try rebasing or merging
your branch first then push.
> On Aug 22, 2019, at 11:11 AM, Bruce Schuchardt wrote:
>
> Using --no-daemon doesn't stop it from launching a daemon. It just tells it
> to shut down the daemon when the build is done.
>
Using --no-daemon doesn't stop it from launching a daemon. It just
tells it to shut down the daemon when the build is done.
On 8/22/19 11:05 AM, Michael Oleske wrote:
Not sure what the exact issue in this particular case, but I suspect we
might not want to run with the Gradle daemon in CI. Th
Not sure what the exact issue in this particular case, but I suspect we
might not want to run with the Gradle daemon in CI. The Gradle daemon is
really meant to help local building (see
https://docs.gradle.org/current/userguide/gradle_daemon.html). That link
explicitly calls out that you may not
