Allow setting multiple docker-compose files

[kasbah]

Hey, I needed to use multiple .yml files so I implemented this. It's been running successfully from this yaml.

It does change one behavior slightly. By default it now calls docker-compose without any -f arguments if stack_file_name is empty. So it's falling back to the docker-compose built-in defaults (which are docker-compose.yml extended by docker-compose.override.yml I recently learned). Hence I would suggest a major version bump if you decide to merge this.

[TapTap21]

@kasbah Thanks for the PR. Before I merge and version bump, could you please explain why this approach is better than just calling the action twice? Since only deploying one compose per invocation keeps it simple.

What is your use case?

[kasbah]

When you call it with multiple compose files they extend each other which allows you to redefine and extend some fields for development and production for instance.

By default docker-compose tries to use two files docker-compose.yml and docker-compose.override.yml (if it exists and you don't have any -f arguments -- which is what the breaking change on this pull request is about). We keep our base config in the docker-compose.yml, our development overrides in docker-compose.override.yml and then for deployement we have another file and call it like this: docker-compose -f docker-compose.yml -f docker-compose.deploy.yml.

Read more about how this works in the compose docs: https://docs.docker.com/compose/extends/

[TapTap21]

@kasbah thanks for the explanation. This is a good addition to the features of this action. I want to do some testing then I'll merge and version bump.

Thanks!

[acrois]

If you look at the way the parameters are injected, you can conclude that the initial -f has already been supplied but is open to more parameters if you want to inject the other files with additional -f parameters, like so:

      with:
        stack_file_name: docker-compose.yaml -f docker-compose.release.yaml

You should also be able to achieve the desired behavior by setting these in a .env file in the root of your working directory:

COMPOSE_PROJECT_NAME=test
COMPOSE_FILE=docker-compose.yaml:docker-compose.release.yaml
COMPOSE_PATH_SEPARATOR=:

The path separator is : so that works by default on MacOS and Linux while the explicit set of the path separator should allow for support of loading the compose files like this in Windows, otherwise you'd need to change it to ; if you are running on Windows, which I typically just skip by adding the last line so I can commit this .env file with sensible development defaults, while deleting it and specifying secure (and vars) values into the Actions ENV for an actual release.

---

so to say you could specify the ENV override for docker compose in the ENV of the workflow

env:
  # Environment
  COMPOSE_PROJECT_NAME: ${{ inputs.project_name != '' && inputs.project_name || vars.COMPOSE_PROJECT_NAME }
  COMPOSE_FILE: docker-compose.yaml:docker-compose.release.yaml
  COMPOSE_PATH_SEPARATOR=:

and not have to change anything at all with this workflow.

I haven't tested the ENV/.env pattern, preferring to go with what I found worked easiest with because passing -f should have priority over the ENV, IIRC.

If .env it is not compatible, it should be compatible allow no docker compose file flag so that this will work.