-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: form_type
and styling
metadata arguments added
#375
Conversation
form_type
and form_type
metadata arguments addedform_type
and styling
metadata arguments added
The example needs the release. So it's invalid until we push a tag
provider/formtype.go
Outdated
// The value have to be string literals, as type constraint keywords are not | ||
// supported in providers. :'( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For future readers wishing to understand the source of our woes, it might be good to add some relevant links to existing issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually do not know what to link 🤔.
// For example, "multi-select" has the type "list(string)" but the option | ||
// values are "string". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be good to explicitly document each type + option value for the possible values of ParameterFormType
below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather defer that to the truth table below. I do not want to document it in 2 places.
// 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) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good spot! 👍
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_type
as a field to parameters. By default, legacy behavior is maintained by deducing the defaultform_type
value 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.