Support config from files and env vars in addition to flags

[drevell]

TL;DR

In the original design doc, we decided to allow all options to be provided by flag, config file, or environment variables. Currently we only support flags, so we need to add support for the other methods.

Config file support is needed for #46.

Detailed design

No response

Alternatives considered

No response

Additional information

No response

[drevell]

cc @verbanicm , I'm starting work on this

[drevell]

After discussing with @sethvargo, we decided to wait to wait to build support for file-based and env-var-based inputs until we have a customer need for this, not counting our own team.

[stytchiz]

Discussed with Dave on chat.

Decision: We'll support a config file for exclusively the input variables i.e. -input="foo=bar". abc command will read them on execution.

e.g.

# abc-inputs.yaml
foo: bar
service_account: 'my-service-account-123'

Running the following command

# with abc-inputs.yaml
$ abc templates render -input="world=jupiter" $TEMPLATE_LOC

is effectively the same as

# without abc-inputs.yaml
abc templates render -input="foo=bar, service_account=my-service-account-123, world=jupiter" $TEMPLATE_LOC

Update: see #49 (comment)

For precedence order , I'm considering following ssh.config's example.
From www.jamesridgway.co.uk/simplify-ssh-with-ssh-config-files

SSH takes the first value it finds for each parameter. Command line arguments take precedent over a user's config file which takes precedence over the system config file and within a configuration file earlier entries take precedent over later entries

[drevell]

cc @sethvargo @verbanicm @dcreey this effort is starting up again, led by @stytchiz. The rationale is that our two main customers, Mike and Dylan, both want it, and much of the work will be reusable for #191.

[dcreey]

My use case is that we generate a root project location in our repo using a template. This process creates a lot of resources that we need to expose downstream for other templates. Each downstream template creates new resources in sub folders (we are creating deployments, experimental projects, and deployment-resources at the x-project level). As long as we can specify which input configs to use in a command via cli flag the proposed design should be sufficient. If you aren't planning on adding a flag to specify input config path please do.

[stytchiz]

@dcreey Yes, we will be supporting a new flag for the file. @drevell and I talked about doing so, but I forgot to update it here.

abc templates render -input_file=$PATH/abc-input.yaml $TEMPLATE_LOC

[stytchiz]

#245 is merged.

@drevell can we close this issue?

[drevell]

#245 is merged.

@drevell can we close this issue?

Sure, let's take it for a quick test drive on the command line first just to make sure everything works as well in reality as it does in tests.

[stytchiz]

➜  hello_jupiter git:(stanchen/issue49) ✗ cat input.yaml 
planet: Jupiter
➜  hello_jupiter git:(stanchen/issue49) ✗ cat spec.yaml 
apiVersion: 'cli.abcxyz.dev/v1alpha1'
kind: 'Template'

desc:
  'Template for printing planet'
inputs:
  - name: 'planet'
    desc: 'foo bar baz'
steps:
  - desc: 'Print "planet"'
    action: 'print'
    params:
      message: 'Hello {{.planet}}'
➜  hello_jupiter git:(stanchen/issue49) ✗ ./abc templates render --input-file=input.yaml .
Hello Jupiter
➜  hello_jupiter git:(stanchen/issue49) ✗ ./abc templates render --input=planet=Mars --input-file=input.yaml .
Hello Mars

[drevell]

Nice, thanks Stanley. This was released in v0.2.1 and is ready to be used (cc @dcreey who wanted to use it)