You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the introduction of ephemeral inputs in terraform 1.10 we finally have a way to utilise sensitive values such as passwords and keys in a plan without them entering the state file.
However - we discovered they do not quite work when using the apply action.
The action itself performs a plan step followed by an apply step. It seems to me that the value for the ephemeral input is present during the plan step, but then not present during the apply step.
....<plan output which obviously meant that the ephemeral input was used during plan phase>
Plan: 0 to add, 0 to change, 2 to destroy.
Automatically approving plan
Releasing state lock. This may take a few moments...
Error: No value for required variable
on variables.tf line 3:
3: variable "cloudflare_api_token" {
The root module input variable "cloudflare_api_token" is not set, and has no
default value. Use a -var or -var-file command line argument to provide a
value for this variable.
Has debug logging been enabled?
Yes, the ACTIONS_STEP_DEBUG secret was set to true when capturing the workflow log above. I understand that if I have not done this, I may not recieve a response.
The text was updated successfully, but these errors were encountered:
Problem description
With the introduction of ephemeral inputs in terraform 1.10 we finally have a way to utilise sensitive values such as passwords and keys in a plan without them entering the state file.
However - we discovered they do not quite work when using the apply action.
The action itself performs a plan step followed by an apply step. It seems to me that the value for the ephemeral input is present during the plan step, but then not present during the apply step.
Terraform version
1.10
Backend
gcp
Workflow YAML
Workflow log
Has debug logging been enabled?
ACTIONS_STEP_DEBUG
secret was set totrue
when capturing the workflow log above. I understand that if I have not done this, I may not recieve a response.The text was updated successfully, but these errors were encountered: