[Feature Request] Setting habitus' args from within build.yml

[mumoshu]

Extracted from #74 (comment)

# NEW: matches to habitus -secret=true -host=192.168.99.1 -binding 192.168.99.1
# But this should be a separate feature request 
secrets: true
host: 192.168.99.1
binding: 192.168.99.1

build:
  version: 2016-03-14 # version of the build schema.
  steps:
  # snip

In this specific example, secrets, host and binding would possibly serve as a sane defaults possibly used across your colleagues' local machines.

host and binding would be overrode via command-line flags when habitus is being run in e.g. your CI builds with a docker setup different than local one.

[khash]

I like the sharing aspect that it brings, but also would like to make sure operational concerns are left outside the development scope. build.yml should remain a developer concern so the same file can be sent over to a build server for example. While it is possible to think of command line parameters overriding the content of the file, it would not be clear and also makes the configuration process messy and potentially expose to security concerns for multi-tenanted environments.

We can potentially solve this by allowing configuration files to be provided as a file and then use conventions to read it from the same location as with the build.yml based on naming conventions.

[mumoshu]

build.yml should remain a developer concern so the same file can be sent over to a build server for example

Good point! This sentence made a lot of sense to me.

At glance, your explanation made me think that secrets: true in build.yml would still make sense to be added without any concern.

But after thinking twice, I now believe secrets should also be avoided. The reasoning is that, we tend to curl http://$host:8080/v1/secrets/$secret_id inside Dockerfile to obtain the secret. Here, whether $host is served by habitus or any other webapp is completely up to the operator. That being said, fixing it as secrets: true in build.yml sounds just wrong.

We can potentially solve this by allowing configuration files to be provided as a file and then use conventions to read it from the same location as with the build.yml based on naming conventions.

Good idea!

Suppose it is named config.yml, I'd want to git-commit multiple different config.yml per build environment(dev, ci), may be encyrpted or not. I'll revisit the idea after I come up with a more concrete use-case.

[mumoshu]

Given the original issue has been discussed and agreed not to be eligible for addition, I'm closing this.
Thanks again for the discussion!