I'm going with this issue. First: we'll introduce the new parameter data source

Battle plan:

• feat: Add basic support for rich parameters to coderd and provisionerd #5710
• feat: Expose workspace build parameters via API #5743
• feat: Add CLI support for workspace build parameters #5768
• feat: Validate workspace build parameters #5807
• feat: Adjust forms to include Rich Parameters #5856
• feat: Support rich parameters in autobuilds #5916
• feat: Disallow using legacy params with rich params #5974
• feat: Group immutable and mutable rich parameters #5975
• rich parameters: support for disk size #5978
• Allow template parameter descriptions to be markdown #5931
• rich parameters: convert Coder examples #6073
• docs: rich parameters #6074
• Rich parameters: remove old parameters #6075

We could warn users in the dashboard and CLI when they interact with a workspace or template configured with the old parameters.

We could warn users in the dashboard and CLI when they interact with a workspace or template configured with the old parameters.

Good call, might be worth discussing.

Currently, the idea is to pull parameters from the previous workspace build, unless the user provided new parameter values via CLI/site. Parameters can also have the default_value property, so altogether we should achieve a really smooth experience - if everything matches, don't need to notify or warn the user. Added template parameters should be resolved to their defaults.

If we need transparency, I can park this for development.

Zoom message from Ammar to address later:

How hard would it be to embed a tool in the coder CLI to rewrite templates for the new parameters?

Okay. That makes a lot of sense. So we can force that users use the new parameters in order to update their workspace configuration.

From Ammar on zoom:

Would be cool if we could show immutable parameters as a section and then mutable as the second section. It creates a clear line for “think hard about these parameters”. It will also lead to more consistency between the edit and create forms.

From Zoom today:

@deansheather:

can we make the edit workspace form look the same as the create workspace form?
like in v1
and just disable the fields that can't change
also the mutable/immutable headers seem odd to me, it'd be nice if users could define their own sections and we just relied on the yellow text that says it can't be changed instead

@ammario

What’s friendlier language we can use instead of “mutable” and “immutable” in the form? I also second Dean’s point. It would be cool if we could reuse the form and show the immutable params as disabled forms so the user is still aware of them. I also think it would be nice if we had a box around the immutable parameters like: https://i.imgur.com/tQ0TOhf.png.

@kylecarbs

i feel like immutable is pretty friendly as code

@ammario

As a section title it’s probably fine since it maps to configuration. We should at least explain what it means in a description / subtitle in the form.

@bpmct Do you think that we can convert the ideas above and these leftovers into smaller issues in favor of this meta-issue?

As agreed during the Weekly call, I converted this issue into smaller action items, hence closing this one.