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 > >> > >
