Environment variable files (i.e ".env") are a commonly used method to define and manage project specific secrets and configuration.

It is standard for yaml-like projects to allow you to access env vars you have defined in env files in your project. For example, Docker Compose will read variables defined in an ".env" file by default without any configuration.

Currently, to access a variable FOO=bar defined in a file ".env" in a command, you would need prepend a source .env to the command each and every time:

source .env && echo $FOO

This is tiresome and error-prone. In my proposed PR, we would allow the user to define global and command-level env files. For example:

ahoyapi: v2
env: .env
commands:
  bar:
    cmd: echo $BAR
  foo:
    cmd: echo $FOO
    env: .env.default

In the case where a command has both the global and command-level env files set, and these files contain conflicting variable definitions, I propose that the command-level env file overrides the global one.

Also, as it is currently implemented the filepath provided to the env: yaml key must be relative to the Ahoy source directory; see for example:

if config.Env != "" {
        globalEnvFile := filepath.Join(AhoyConf.srcDir, config.Env)
	envVars = append(envVars, getEnvironmentVars(globalEnvFile)...)
}