@johnstcn@matifali should this pass a template import?

Before this PR, this would pass aterraform plan.

data"coder_parameter""region" {name="region"description="Which region would you like to deploy to?"type="string"order=1option {name="Europe"value="eu"  }option {name="United States"value="us"  }}

EDIT: Test case here

This PR sets the error to:

Planning failed. Terraform encountered an error while generating this plan.╷│ Error: Value must be a valid option. The value is empty, did you forget to set it with a default or from user input?│ │   with data.coder_parameter.region,│   on main.tf line 21, in data "coder_parameter" "region":│   21: data "coder_parameter" "region" {│ │ the value "" must be defined as one of options

To fix this, either the value must be passed via an env var:

CODER_PARAMETER_c697d2981bf416569a16cfbcdec1542b5398f3cc77d2b905819aa99c46ecf6f6=us terraform plan

Or with a default:

data "coder_parameter" "region" {  # ...  default = "us"  # ...}

I feel like we should reject it? But that is a breaking change.

There are use cases where an admin may not want to set a default to force the user to choose an option. At least it was possible before this PR. I am not sure how many users were actually using it.

But I have seen requests to supportcoder_parameter without a default value better:#144

There are use cases where an admin may not want to set a default to force the user to choose an option.

This behaviour is problematic because you could end up with a plan that does not correspond to the apply, depending on how the value of the parameter is used.

Would marking the parameter asephemeral be a possible workaround here?

EDIT: marking a parameter as ephemeral requires it to be mutable and to also have a default set. This may not suit certain use-cases.

Do we require a user input if the parameters are ephemeral? Do we not allow setting a default value for such parameters?
Do such ephemeral parameters support options too?

If the answers are yes, then we just need better docs on how to fulfill this use case.

So that people don't try to use the existing non ephemeral parameters.

@matifali@johnstcn

How I see it is the relaxed validation on template import is incorrect. If a parameter has 0 values, but will have some value at workspace create, then theterraform plan could be incorrect.

However, I understand the use case. The provider SDK we are using does not indicate anywhere ifterraform plan vsterraform apply is being run. So there is no way to conditionally enforce validation that way.

My gut thought is that we need to effectively have 2 modes of validation. 1 for template import, 1 for workspace create, where the latter is strict. The strict validation is the most correct.

What if we pass through an env var a relaxed validation mode?coder/coder can passCODER_VALIDATION=relaxed when doing a template import. Then the provider can acceptnull values.

What if we pass through an env var a relaxed validation mode?coder/coder can passCODER_VALIDATION=relaxed when doing a template import. Then the provider can acceptnull values.

I think this approach could work, but we'd want to perhaps tie its behaviour specifically to what "operation" we're doing in Coder. We might also want to be wary of folks just setting this env var on the provisioner to work around null values entirely.

I think this approach could work, but we'd want to perhaps tie its behaviour specifically to what "operation" we're doing in Coder. We might also want to be wary of folks just setting this env var on the provisioner to work around null values entirely.

Yes, template import would have to pass some env var to change the behavior.

As for folks setting this env var at home, I think that would just be on them. By default the validation should be handled correctly in coder (when to be relaxed, and when not)

As for folks setting this env var at home, I think that would just be on them. By default the validation should be handled correctly in coder (when to be relaxed, and when not)

If provisionerdalways sets the environment variable before exec'ing terraform, then I don't think we need to worry about users setting it.

It seems very odd to me that in this PR, template-import mode, which is supposedly being created for back-compatibility is more strict than what you're calling default mode.

Shouldn't it be the other way around? That template-import mode skips some checks that would break backward compatibility?

Maybe I should have broken this into 2 PRs. My goal is to make existing imported templates backwards compatible. They will function as they used to.

Future imported templates I am closing some of the validation holes.

And the backwardsfeature I am keeping, is allowing empty andefault value. So this isstill valid:

data"coder_parameter""region" {name="region"description="Which region would you like to deploy to?"type="string"order=1option {name="Europe"value="eu"  }}

The other changes I made are fixing validation bugs. Meaning validation used to be skipped on present values.

Validating input values is in the option set

This is incoder/coder. This change shifts some of the validation incoder/coder ->terraform-provider-coder.

This is now invalid except attemplate-import, since no input values are given. So attemplate-import, there is no change in behavior here.

# Using input value 3# CODER_PARAMETER_f3c7807d475073ba009bf4801b2d934e9f0126cb96dd19a27dbffcae23a7f5a3=3 terraform plandata"coder_parameter""numbers" {name="numebrs"type="number"order=1option {name="Five"value="5"  }}

Validating option values

This used to pass, and it will continue to passcreate so that previous templates still build if they have been imported. I cannot break existing imported templates.

For futuretemplate-imports, I throw an error. I think this fix can be seen as a bug fix. Otherwise, dropdown options in the UI form will fail when you select them.

data"coder_parameter""numbers" {name="numebrs"type="number"order=1default=7validation {min=6max=10error="The number must be between 6 and 10"  }option {name="Seven"value="7"  }option {name="Four"value="4"  }}

│ Error: Option "Four": Invalid parameter value according to 'validation' block│ │   with data.coder_parameter.numbers,│   on main.tf line 10, in data "coder_parameter" "numbers":│   10: data "coder_parameter" "numbers" {│ │ The number must be between 6 and 10

If provisionerdalways sets the environment variable before exec'ing terraform, then I don't think we need to worry about users setting it.

I agree, I was asked this in a voice chat. It can be set by users, but I don't imagine they will.

I removed the idea of 2 validation modes. There is only 1.option values are not validated, just as they were previously skipped.

The new validation mode is backwards compatible in all intended behavior.