Allow concurrency (e.g. multiple integration tests at once) out-of-box

[briceburg]

Thanks for the awesome plugin!

I'm using it in our CI build process, and have to manually set the projectName to ensure it's unique to support concurrent builds.

It would be convenient to support concurrency out of box by allowing us to provide a prefix to be used when the compose project name is generated versus relying on the MD5 sum of the project directory as a prefix. It also gives us something more friendly to see and debug when using docker ps and such.

[briceburg]

Example Usage:

Imagine the CI/build environment sets PIPELINE_ID to something like GIT_BRANCH-BUILD_NUMBER, e.g. master-88. We can use this to prefix our compose project name and support concurrent builds via:

dockerCompose {
    removeOrphans = true
    projectNamePrefix = System.getenv("PIPELINE_ID") ?: "local-0"
    ...
}

[augi]

Hello, thank you for suggesting this improvement!

Actually, I'm not sure if I fully understand your use-case. Why is it not please just projectName = System.getenv("PIPELINE_ID") sufficient for you? I'm asking because we heavily use this plugin on our projects (in Jenkins, TeamCity, TravisCI, ...) and this works perfectly for us.

[briceburg]

Thanks Augi and yes -- a great question. The main reason is I wanted to maintain the nested configuration name without having to repeat it. So given the following configuraton;

dockerCompose {
    dockerComposeWorkingDirectory = 'stacks.d/cfp-local'

    pipeline {
        projectNamePrefix = System.getenv("PIPELINE_ID")
        dockerComposeWorkingDirectory = 'stacks.d/cfp-pipeline'
        isRequiredBy(test)
    }
}

our project name automatically will end in "${project.name}_pipeline". otherwise we would have to redefine it all in the projectName: projectName = System.getenv("PIPELINE_ID") + "${project.name}_pipeline" -- so using the prefix maintains the natural naming in less code.

the second reason is to allow us to use something other than the MD5 if we prefer.

It also restores the functionality of using compose defaults when setting projectName = null

make sense?

[augi]

Btw. if you understand it correctly - you are executing the same project (from exactly the same file-system location) more times in parallel, right? This means that you have project name conflict, right?

Speaking about preserving the previous naming by setting projectName to null - this is what we cannot do :( This plugin has too many users to make this kind of breaking change.

I could prepare another PR that would solve your issue in proper (~backward compatible) way - would it be OK for you?

[briceburg]

Yes we are executing concurrently from the same pseudo FS location. FWIW I Imagine whoever has set projectName = null in their configuration to expect the documented behavior and would welcome the fix. The PR maintains the current behavior of MD5 prefix and double trailing _ when a nested project is not used.