[Feature Request] Setting habitus' args from within build.yml about habitus HOT 3 CLOSED

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.

from habitus.

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.

from habitus.

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

from habitus.