Repository-local configuration

[pbrisbin]

Repository-local configuration

If present, ./.stackctl/config.yaml is read on startup and loaded into an application Config value. This configuration provides two abilities:

• To specify a version requirement, in case your specs are relying on certain Stackctl features and/or bugfixes and you'd like to fully ensure behaviors in both local and CI contexts

• To specify some defaults: Parameters or Tags that should be applied to all Stacks deployed from this location. For example, App, Owner, or DeployedBy. It's tedious and error-prone to have to specify repeated things in every specification.

The config currently look like this (all values optional):

required_version: <RequiredVersion>

defaults:
  parameters:
    <ParametersYaml>

  tags:
    <TagsYaml>

And here is an example:

required_version: =~ 1.2

defaults:
  parameters:
    App: my-cool-app

  tags:
    Owner: my-cool-team

To support this,

• RequiredVersion was built and tested
• ParametersYaml and TagsYaml were given "last-wins" Semigroup instances
• Config and HasConfig were built
• StackSpec construction was centralized in buildStackSpec, which grew a HasConfig constraint, which it now uses to apply defaults for every StackSpec we ever construct

Search for the config in a few locations

[joelmccracken]

Looks fine, makes sense. Comment on the Last business but eh, up to you. I always learn something new reading your PRs Pat, usual several new things!

[pbrisbin]

Comment on the Last business but eh, up to you.

It's a very fair point. I originally did ParameterYaml Key (Last ParameterValue), which I think is much clearer to the intent: merging a parameters object should combine the keys with last semantics. But I found that broke the JSON instance; it stopped using the custom "parse a string or number" behavior of ParamaterValue. So I ended up encoding "combining parameter values has last semantics themselves", which I agree is "eh". I'm going to go back to how I originally wanted it and investigate the broken JSON instance some more. Appreciate you pointing it out!

I always learn something new reading your PRs Pat, usual several new things!

That's great to hear, thank you!