-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable overriding create_cmd_triggers completely #39
Comments
I assume what you're trying to do is have the create command body excluded from the destroy triggers. This will not work, because Terraform requires that all values accessed in the provisioner are referenced from triggers. I don't like it either, but there's no workaround possible besides fixing Terraform core. Background here: hashicorp/terraform#23679 |
@morgante I have been investigating this for a bit. Is it reasonable for the kubectl submodule to generate kubeconfig on the fly using |
I'd like to avoid using |
@morgante even with the |
@bharathkkb We'd use the auth module to generate a kubeconfig file (with a static path). The gcloud module would then reference the kubeconfig file and not need to return each time. |
Cool I can give that a try. My thought was since the |
I have been testing this out
This had two drawbacks
In this case, my If you have other ideas I would be happy to test them out. |
This could probably be fixed by using How about we just add |
I did try with
Sounds good, I will give that a go. |
I am using this module to deploy a Kubernetes resource foo like so
Problem:
However due to
data.google_client_config.default.access_token
changing between Terraform plans this causes noise in the diff as well as blows away and recreates the foo resourceProposal:
Either let
create_cmd_triggers
overridetriggers
completelynew var
create_cmd_triggers_override
if set completely overrides the triggersOpen to other suggestions or if I am missing something here
The text was updated successfully, but these errors were encountered: