Open abennett opened 2 years ago
We're trying to keep a clear boundary between the scope of our Terraform provider, and spacectl
. The latter is supposed to do things that are not a great fit for the former. Since managing the lifecycle of resources like contexts is generally handled by IaC, I'd be curious to learn what your use case is @abennett? Why would you need to create contexts from the CLI as opposed to writing a bit of Terraform?
Hey, @marcinwyszynski!
Our AWS roles that Spacelift uses are configured without the ability to mutate IAM as an additional risk mitigation. To compensate for this, I have written an accompanying CLI that goes through the following steps:
I suppose it is a bit niche, and I am pretty satisfied with my custom solution if we wanted to avoid exposing contexts in spacectl.
I also have a use for interacting with contexts via the API, I have intentionally decoupled a particular piece of configuration from terraform as it's not clean or easy to manage it there. So I have a small script to add an environment variable and update it, the rest of the context is managed with terraform though.
@marcinwyszynski I think your point is totally fair, but it would be nice to have the spacectl tool be able to do it, if not with spacectl what would be the best way to do this?
As an aside, I don't see why read only sorts information couldn't be available, I would get a lost of use out of it and it would save a lot of time clicking about the UI.
I'm interested in adding a new set of subcommands like:
context create
context update
context delete
context list
But I would like to solicit input of how the inputs should be supplied, with special consideration for sensitive
writeOnly
values.