feat: form_type and styling metadata arguments added#375
Merged
Conversation
form_type and form_type metadata arguments addedform_type and styling metadata arguments added
8 tasks
The example needs the release. So it's invalid until we push a tag
johnstcn
reviewed
Apr 8, 2025
provider/formtype.go
Outdated
Comment on lines
+14
to
+15
| // The value have to be string literals, as type constraint keywords are not | ||
| // supported in providers. :'( |
Member
There was a problem hiding this comment.
For future readers wishing to understand the source of our woes, it might be good to add some relevant links to existing issues.
Member
Author
There was a problem hiding this comment.
I actually do not know what to link 🤔.
Comment on lines
+37
to
+38
| // For example, "multi-select" has the type "list(string)" but the option | ||
| // values are "string". |
Member
There was a problem hiding this comment.
Might be good to explicitly document each type + option value for the possible values of ParameterFormType below.
Member
Author
There was a problem hiding this comment.
I'd rather defer that to the truth table below. I do not want to document it in 2 places.
Comment on lines
+194
to
+198
| // TODO: We do this unmarshal in a few spots. It should be standardized. | ||
| err = json.Unmarshal([]byte(parameter.Default), &defaultValues) | ||
| if err != nil { | ||
| return diag.Errorf("default value %q is not a list of strings", parameter.Default) | ||
| } |
johnstcn
approved these changes
Apr 8, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is in support of dynamic parameters. Changes to coder/coder intends to support this experimentally by the end of April. For current versions of coder, these arguments will be ignored.
What is this?
This adds
form_typeas a field to parameters. By default, legacy behavior is maintained by deducing the defaultform_typevalue from the existing inputs.Why do this?
To support more form type options in the UI. See the truth table here of all the new types:
terraform-provider-coder/provider/formtype.go
Lines 74 to 91 in 2b5ff08
Example new param
Note on docs
I am unable to add more example params to the docs, as they are used in integration tests that seem to use provider versions without this change? I get this error for above:
That error is the error you get using this param on the existing terraform provider. Maybe I have to do some skips with past versions. Regardless, I will update the docs when this gets further upstream to a release.