search

plumber-cd / terraform-backend-git

Terraform HTTP Backend implementation that uses Git repository as storage
Apache License 2.0
198 stars 19 forks source link

Allow starting the server backend with a config file #18

Closed RickyGrassmuck closed 2 years ago

RickyGrassmuck commented 3 years ago

This facilitates having the wrapper utilize the server backend.

The end workflow ended up with:

See https://github.com/plumber-cd/terraform-backend-git/issues/16#issuecomment-791063691 for more context.

dee-kryvenko commented 3 years ago

Sorry that I didn't responded anything - I actually did looked into this PR and I wanted to modify it slightly to allow for a possibility of multiple config files on different levels that would override each other. So that we could have some sort of a "system" config and then per-module config overriding or expanding on the system baseline. Just haven't had a chance to look into it yet.

dee-kryvenko commented 3 years ago

Hey @rigrassm - my apologies, I only got to this PR now. My understanding is that with this PR - storage implementation now could read from config file and CLI args directly via viper.

I am trying to understand what is the intention in doing this though. Backend configuration in the terraform block was already optional (you could do terraform-backend-git git terraform apply -input=false awesome.plan as long as the config file present in the folder).

The idea in current implementation was that the backend will read config file and/or CLI args and generate tf block with a full configuration ready to be consumed by the storage (in the form of HTTP params). The intention in doing it that way was - so that the storage configuration doesn't know/care where the input came from, so there is less scenarios to test and overall we have storage implementation loosely coupled with the backend.

I'm just trying to understand - is there anything wrong with the current approach we need to fix? Is that because you want to hide full backend configuration details from the TF files? I just want to make sure I understand what we need to do here - there might be something else we'd need to refactor with this change, as well as update documentation properly.

dee-kryvenko commented 2 years ago

As there is no feedback from the author on my last message - I am going to close this. I think it is best to keep backend implementation agnostic of the frontend CMD implementation, that way this project can also be used as a library in other implementations.