Add Support for System Environmental Variables - v1

[laardee]

This is version 1. In this version, there are no prefixes in the parameters, if a component is not found with that name, it tries to use an environmental variable.

A dummy test service yaml, executed with NAME=name STAGE=dev slsdev

name-dev: dev-service
envStage: ${STAGE}
envName: ${NAME}
name: ${${envName}-${envStage}} # first resolves to '${name-dev}' and then to 'dev-service'

# this is just a mock component, it only passes inputs to output
test-component:
  component: "../env-vars"
  inputs:
    stage1: ${STAGE}
    stage2: ${envStage}
    name: ${name}

output is

  test-component: 
    stage1: dev
    stage2: dev
    name:   dev-service

[eahefnawy]

Thanks @laardee ... That's an interesting approach. What if there's a property in the yaml file with the same name? so running with STAGE=prod on this yaml...

STAGE: dev

# this is just a mock component, it only passes inputs to output
test-component:
  component: "../env-vars"
  inputs:
    stage: ${STAGE}

Would that pick up dev or prod?

[laardee]

@eahefnawy In this approach, the "hardcoded" variable is prioritized. So that would pick prod, which would prevent overwriting components with variables. Otherwise this

$ test-component=something sls

would break this

test-component:
  component: "../env-vars"
  inputs:
    stage: ${STAGE}

because the component would be overwritten with string something.

I'm not sure if this is a good idea, this was kind of a test if the syntax could be this simple.