Vince just told me that we can't use Docker in Windows. So that's one downside.
On Thu, Aug 24, 2017 at 7:27 AM, Darrel Schneider <dschnei...@pivotal.io> wrote: > I like the sound of #1: > 1) use Docker for AcceptanceTest and IntegrationTest targets? > > Does anyone know of a downside to running these tests in docker? > > On Wed, Aug 23, 2017 at 12:06 PM, Jared Stewart <jstew...@pivotal.io> > wrote: > > > I think we just need to have AcceptanceTest (and possibly > IntegrationTest) > > run inside Docker like DistributedTest already does. > > > > - Jared. > > > > > On Aug 23, 2017, at 11:32 AM, Anilkumar Gingade <aging...@pivotal.io> > > wrote: > > > > > >>> 1) use Docker for AcceptanceTest and IntegrationTest targets? > > > To be clear, the failing tests are only in Acceptance Test and > > Integration > > > Tests? And distributed tests are not seeing this issue as they are > > running > > > in docker now....If moving docker address this issue, my vote is for > > moving > > > docker; this makes all the tests to be run in similar environment. > > > > > >>> 2) not test default ports? > > > If the product supports default port; we need to have test for > > that...Most > > > of the early product evaluation is done with default port... > > > > > > -Anil. > > > > > > > > > On Wed, Aug 23, 2017 at 11:15 AM, Kirk Lund <kl...@apache.org> wrote: > > > > > >> The following nightly build failures are tests that are testing > default > > >> ports which are failing because the port is not available. > > >> > > >> Should we: > > >> > > >> 1) use Docker for AcceptanceTest and IntegrationTest targets? > > >> > > >> 2) not test default ports? > > >> > > >> 3) use a hacky System property to force Geode to think that some other > > port > > >> is the default port? > > >> > > >> 4) some other solution? > > >> > > >> testGet – org.apache.geode.rest.internal.web.RestServersJUnitTest > > >> a few seconds > > >> testServerStartedOnDefaultPort – > > >> org.apache.geode.rest.internal.web.RestServersJUnitTest > > >> a few seconds > > >> offlineStatusCommandShouldSucceedWhenConnected_server_dir – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> offlineStatusCommandShouldSucceedWhenConnected_server_pid – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> offlineStatusCommandShouldSucceedEvenWhenNotConnected_server_dir – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> offlineStatusCommandShouldSucceedEvenWhenNotConnected_server_pid – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> onlineStatusCommandShouldSucceedWhenConnected_server_name – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> offlineStatusCommandShouldSucceedWhenConnected_locator_dir – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> offlineStatusCommandShouldSucceedWhenConnected_locator_pid – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> onlineStatusCommandShouldSucceedWhenConnected_locator_name – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> onlineStatusCommandShouldSucceedWhenConnected_locator_port – > > >> org.apache.geode.management.internal.cli.shell. > > >> GfshExitCodeStatusCommandsTest > > >> a few seconds > > >> statusLocatorSucceedsWhenConnected – > > >> org.apache.geode.management.internal.cli.commands. > > >> StatusLocatorRealGfshTest > > >> > > > > >
