Randomized project names exhausts docker's networks

[palantir]

Randomized project names exhausts docker's networks

[joelea]

It caused issues with running tests in parallel.

[CRogers]

Yes, imo the default should be randomised project names or you get all
kinds of problems with parallel tests.

docker-compose down removes networks. We should be calling that after
running each test. Is this only something that affects people who choose to
not destroy the composition (and so not call down) afterwards? If so, maybe
we should warn them to give a fixed project name and about the networks
problem.

On Thu, 1 Sep 2016, 12:35 joelea, [email protected] wrote:

It caused issues with running tests in parallel.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#99 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYR48BUTLOr3GNTZxEnx5xsJMP_aEVTks5qlriNgaJpZM4Jyjek
.

[CRogers]

I just read #40. Are we still using ExternalResource? That has some weird semantics iirc, like not calling after if there was an exception, which could be exacerbating the problem.

[j-baker]

I think the ExternalResource

    private Statement statement(final Statement base) {
        return new Statement() {
            @Override
            public void evaluate() throws Throwable {
                before();
                try {
                    base.evaluate();
                } finally {
                    after();
                }
            }
        };
    }

is safe for that, no?

[j-baker]

ah wait - the failure is if the error is in your before method; before should be in the try block. That's what could exacerbate the problem.

[iamdanfox]

@joelea can you elaborate on the "issues with running tests in parallel" you mention... do you mean running multiple instances of the same class at the same time? Or just multiple test classes that happen to be in the same folder?

[j-baker]

E.g. If you have two projects that both use the same docker compose file in different contexts, you can't run ./gradlew test --parallel. You can't e.g have a dev stack running and run the tests on a different cluster.

The bug here btw is that DCR can terminate having made no attempt to clean up its state. If DCR creates a network, it should delete it too, whether or not before() throws.

On Sep 30, 2016, at 20:58, iamdanfox <[email protected]mailto:[email protected]> wrote:

@joeleahttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_joelea&d=DQMGaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=mzXajGbPp7kc5a_CRzXttisFRf8mEsV3gcMrXd3MRoc&m=6p6JDu3oI16wHgpBHvaNj51NY70WogomHlUG1KYAy8w&s=E6OQAKKrmd8TBW7uwGiANF_0mStlG0xAdQq4Omr-X-4&e= can you elaborate on the "issues with running tests in parallel" you mention... do you mean running multiple instances of the same class at the same time? Or just multiple test classes that happen to be in the same folder?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_palantir_docker-2Dcompose-2Drule_issues_99-23issuecomment-2D250837960&d=DQMGaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=mzXajGbPp7kc5a_CRzXttisFRf8mEsV3gcMrXd3MRoc&m=6p6JDu3oI16wHgpBHvaNj51NY70WogomHlUG1KYAy8w&s=g85uuIvOgT7XEWfBPNm2Dv_Wj0cnp4nBlDUpwgkX75o&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AACmJW0WZZqOgzlVsgg9OplmkpNSnUZ8ks5qvWnUgaJpZM4Jyjek&d=DQMGaQ&c=izlc9mHr637UR4lpLEZLFFS3Vn2UXBrZ4tFb6oOnmz8&r=mzXajGbPp7kc5a_CRzXttisFRf8mEsV3gcMrXd3MRoc&m=6p6JDu3oI16wHgpBHvaNj51NY70WogomHlUG1KYAy8w&s=wI31cg1BQtV4IgtyPtPMXBGSCeh0NiUnKUNPe-vqW34&e=.