support array of docker-compose files

[ghost]

http://groupon.github.io/DotCi/user-guide/DockerCompose .ci.yml

docker-compose-file: "./jenkins/docker-compose.yml"

Currently, the code does not support an array of docker compose files

            if (dockerComposeCommand != null ) {
                shellCommands.add(String.format("docker-compose -f %s run -T %s %s", fileName, dockerComposeContainerName,SHELL_ESCAPE.escape((String) dockerComposeCommand)));
            }
            else {
                shellCommands.add(String.format("docker-compose -f %s run -T %s",fileName,dockerComposeContainerName));
            }

https://docs.docker.com/compose/extends/#understanding-multiple-compose-files says

By default, Compose reads two files, a docker-compose.yml and an optional docker-compose.override.yml file. By convention, the docker-compose.yml contains your base configuration. The override file, as its name implies, can contain configuration overrides for existing services or entirely new services.

Ideally instead DotCi could default to reads two different set of files, a docker-compose.yml and an optional docker-compose.dotci.yml, if available. This way the default docker-compose.override.yml best represents local developer environment. For example it can be configured to statically bind local ports for testing on dev machine. Whereas DotCi version can NOT perform static binding since parallel builds and other projects on the same slave would fail if that port is already bound.

This feature will help reinforce developer to be aware that docker-compose can support multiple files. The docker-compose.yml is to be a shared common definition that can be reused on localhost, dotci, and production. It should NOT contain test definition per best practice outlined in

https://docs.docker.com/compose/production/

$ docker-compose -f docker-compose.yml -f production.yml up -d

[ghost]

see https://github.com/groupon/DotCi/issues/46 on pitfuls to avoid.

This supports why an array is necessary, so dev can make necessary changes to docker for ci .... w/o effecting production docker image.