K-V Pair File Support

[jenpet]

Hey guys, what you think of a possibility to pass key-value pair files (e.g. .env) to robo which will be processed before running a certain task? It would be similar to the functionality of the currently supported envs but a bit more flexible if we can just specific a env file instead of (or additionally to) a set of env vars for task.

Especially when it comes to more complex configurations where the local environment might differ quite heavily between the dev setups / machines it becomes very messy because I currently see only two options:

• manually setting a list of individual env vars in .bashrc; wherever
• putting them in the robo.yml file (… and eventually checking them in ☠️ )

Am I missing something regarding robo's functionality or would you consider this a feature we could think about?

[yields]

putting them in the robo.yml file (… and eventually checking them in ☠️ )

This seems to suggest that checking them in is not good, are there any secret env vars that you would like to add?

Hey guys, what you think of a possibility to pass key-value pair files (e.g. .env) to robo which will be processed before running a certain task?

I don't mind the idea, I've never really needed it but I wouldn't block adding it if you find it useful, one thing that may complicate things is say how do we resolve the absolute file path? we may need to add a join() func:

envfile: {{ join(robo.path, "vars.env") }} # join() needed to work on unix and windows.

Especially when it comes to more complex configurations where the local environment might differ quite heavily between the dev setups / machines it becomes very messy because I currently see only two options:

Where I work we use different tools and use robo to wrap them, for example we use aws-okta(1), developers typically set things up using robo setup.aws (just calls aws-okta setup) and then use robo dev aws <args...>, so we let aws-okta handle configuration, same goes for kubectl(1) etc..

[jenpet]

Hey there, sorry for the late reply!

I'd like to elaborate a bit more on the feature I want to address. Let's assume you don't have something like k8s or AWS under the hood and just wanna run an application plain based on environment variables. If I'm not mistaken, at the current stage I would've to specify multiple jobs for different environments like:

run-dev:
  summary: build and run the application in a dev environment
  command: |
    robo -c {{ .robo.file }} build && \
    ./{{ .binary }}
  env: 
    - "DEV_DB_CONNECTION=postgres://"
    - "PORT=3002"
    - ...

run-prod:
  summary: build and run the application in a prod environment
  command: |
    robo -c {{ .robo.file }} build && \
    ./{{ .binary }}
  env: 
    - "DEV_DB_CONNECTION=postgres://"
    - "PORT=3003"
    - ...

It would be nice if I could specify an environment variable file instead of multiple environment variables in the job, or even additionally, which gets processed and set before (?) the actual "env" section. So especially if running a local dev environment developers do not need not need to check in their credentials.

run:
  summary: build and run the application
  command: |
    robo -c {{ .robo.file }} build && \
    ./{{ .binary }}
  env-file: 
    - ".env" // hardcoded so that the content may vary

It might be even more beneficial if that could be specified when calling the command.

robo run --env-file=".env .env.local"
or
robo run --env-file=".env .env.prod"

Maybe I'm a bit distracted by the usage of env files and docker-compose configuration files and don't see an already existing approach for this. Open for discussion :-)

[yields]

So I think this is a valid feature request, but before we go off and add another feature I wanted to bring some alternatives that might work for you.

1. At work, we have multiple environments, dev, stage, prod so the example below shows how you can chain/isolate commands:

dev:
  summary: Development commands
  exec: robo --config {{ .robo.path }}/remote.yml
  env: [
    "ROBO_ENV=dev"
  ]

stage:
  summary: Staging commands
  exec: robo --config {{ .robo.path }}/remote.yml
  env: [
    "ROBO_ENV=stage"
  ]

prod:
  summary: Production commands
  exec: robo --config {{ .robo.path }}/remote.yml
  env: [
    "ROBO_ENV=prod"
  ]

Note how they all use the same robofile ./remote.yml, the only thing that changes is the ROBO_ENV, which is used by all scripts in ./remote.yaml to ensure that we don't run destructive commands in production, but you can use it to simply source a local env vars file based on the env, so in each script you would do source $ROBO_ENV.

There's a similar example here: https://github.com/tj/robo/blob/master/_examples/chain/root.yml

2. Another approach is to simply inline the source call?

// dev.yml
psql:
  summary: Connect to dev DB.
  command: |
    source $VARS
    psql $DATABASE_URL
  env: ["vars={{ .robo.path }}/.env.dev"]

Those two approaches might be annoying depending on your circumstances, for example there might be too much repetition, if they don't work for you let me know and we can see if we can add env files. :)