Support multiple `.env` files

[AlexSkrypnyk]

126 has added support for reading .env files.
I would like Ahoy to support loading from multiple .env files:

ahoyapi: v2
env: 
  - .env
  - .env.local

Similar approach exists in Docker Compose.

If a file does not exists - it should be skipped and no error would be triggered.

[ocean]

Sounds fair enough @AlexSkrypnyk

What would your expected behaviour be for variables declared in multiple files, that a variable in a later file (further down the list) takes precedence and overwrites the same variable in the earlier file?

E.g.

ahoyapi: v2
env: 
  - .env
  - .env.local

.env:

VAR=foo

.env.local:

VAR=bar

Ends up with VAR equal to bar inside running Ahoy?

[AlexSkrypnyk]

yes, the later value wins

[jackwrfuller]

@AlexSkrypnyk I've had a go implementing this, would you be able to review?

A few notes:

• As the env field is now a []string, it is necessary to change how an env file is defined in the ahoy yml file to

env:
  - .env

even if there is only one env file.

• You said: "If a file does not exists - it should be skipped and no error would be triggered." As Ahoy currently works, if an incorrect env filepath is provided, it returns a failure status. As the MR currently stands, I've kept that behaviour as is. Do you envising people using both a dev and production env file and including both so that the ahoy command works across environments automatically?

[ocean]

@jackwrfuller I understand why you've kept the behaviour for nonexistent .env files the same as it is for Ahoy config files, however I think I agree with Alex in that the behaviour should be that they are ignored if nonexistent, as that would make it more flexible for the example you suggest - people could have multiple ones for different environments and they only override each other if they exist.

Are you able to alter the MR to switch to this behaviour?

[AlexSkrypnyk]

If a file does not exists - it should be skipped and no error would be triggered.
In Docker Compose, they allow to control this with an additional property, converting each entry of env: to a map of these properties.

I think we should avoid such overcomplicated approach and just skip without an error.