Is there a supported migration path forlist(string) variables, or is it best to create a new string parameter (for example, CSV-formatted) and support both the legacy variable and the new parameter during the migration period?

Is there a supported migration path for list(string) variables, or is it best to create a new string parameter (for example, CSV-formatted)

So far we don't plan to add more types tocoder_parameter, so you may want to "downgrade" to an ordinary string. BTW if you find it useful, please open an issue, describe your use case, and we can review it together.

support both the legacy variable and the new parameter during the migration period?

I will improve docs here, and describe the recommended workflow as part of#6074. Is this parameter intended to be modified by users? Maybe you want to rather keep it as managed Terraform variable.

So far we don't plan to add more types tocoder_parameter, so you may want to "downgrade" to an ordinary string. BTW if you find it useful, please open an issue, describe your use case, and we can review it together.

The existing variable is used to specify a free-form list of security groups for the workspace. I had planned to convert this to a comma-separated string when I transition to rich parameters, but I'm a little unclear on the migration path - it sounds I will need my own logic to pull the value from either thecoder_parameter or the TF variable, as applicable.

I will improve docs here, and describe the recommended workflow as part of#6074. Is this parameter intended to be modified by users? Maybe you want to rather keep it as managed Terraform variable.

Yes, the parameter is for users to modify. I thought that support for legacy variables was planned to be removed in April?

The existing variable is used to specify a free-form list of security groups for the workspace.

Well, so far we can supportstring + single choice options,bool, andnumber types.

but I'm a little unclear on the migration path - it sounds I will need my own logic to pull the value from either the coder_parameter or the TF variable, as applicable.

I described the migration stepshere. As you can see, you can configurelegacy_variable_name andlegacy_variable to point to the legacy parameter, and make the migration smoother.

Yes, the parameter is for users to modify. I thought that support for legacy variables was planned to be removed in April?

That is correct, but it doesn't mean that we will remove variables from Terraform templates. Those will be still available to use viamanaged Terraform variables (see:#5980).

but I'm a little unclear on the migration path - it sounds I will need my own logic to pull the value from either the coder_parameter or the TF variable, as applicable.

I described the migration stepshere. As you can see, you can configurelegacy_variable_name andlegacy_variable to point to the legacy parameter, and make the migration smoother.

Right, but I'm assuming that won't work for alist(string) legacy variable. Is that incorrect?

Yes, the parameter is for users to modify. I thought that support for legacy variables was planned to be removed in April?

That is correct, but it doesn't mean that we will remove variables from Terraform templates. Those will be still available to use viamanaged Terraform variables (see:#5980).

The link says "Workspace users are not able to modify template variables", so it sounds ilke I will need to convert this to acoder_parameter one way or another.