feat: allow number options with monotonic validation

[dannykopping]

Fixes #11579

NOTE: terraform-provider-coder was updated to facilitate this change, and your template will require v0.19.0 for this feature to work. You can run terraform init -upgrade in your template directory. If you have a version constraint set, ensure it points to this version.

This PR just does some light refactoring / cleanup; the real work was done in coder/terraform-provider-coder#202.

Initially we planned to extend validation in both the browser & CLI UIs, but we agreed to defer this until #7099 is implemented which would centralise all the logic. Right now the UIs don't validate the monotonicity before submit, but there is still backend validation of course.

Here's an example of how to use the new functionality:

data "coder_parameter" "home_volume_size" {
  name        = "Home Volume Size"
  description = <<-EOF
  How large should your home volume be?
  EOF
  type        = "number"
  default     = 30
  mutable     = true
  order       = 3

  option {
    name  = "30GB"
    value = 30
  }

  option {
    name  = "60GB"
    value = 60
  }

  option {
    name  = "100GB"
    value = 100
  }

  validation {
    monotonic = "increasing"
  }
}

Examples:

[mtojek]

Initially we planned to extend validation in both the browser & CLI UIs

I don't remember now if CLI supports validation of monotonicity. As long as it uses codersdk.ValidateWorkspaceBuildParameters, it should be supported. Maybe drop another CLI test to verify the behavior?

, but we agreed to defer this until #7099 is implemented which would centralise all the logic.

Since validation might work well on the CLI, I'm wondering if it isn't a low hanging fruit to come up with a temporary fix for the frontend. I'm unsure how frontend deals with monotonicity right now.

[dannykopping]

Initially we planned to extend validation in both the browser & CLI UIs

I don't remember now if CLI supports validation of monotonicity. As long as it uses codersdk.ValidateWorkspaceBuildParameters, it should be supported. Maybe drop another CLI test to verify the behavior?

The CLI doesn't seem to have any client-side validation for options that I can see. The survey lib which powers the options selector exposes a WithValidator hook which we could implement?

, but we agreed to defer this until #7099 is implemented which would centralise all the logic.

Since validation might work well on the CLI, I'm wondering if it isn't a low hanging fruit to come up with a temporary fix for the frontend. I'm unsure how frontend deals with monotonicity right now.

Frontend validation can work but it's not possible to display the error inline with the RadioGroup component according to @BrunoQuaresma.

[mtojek]

The CLI doesn't seem to have any client-side validation for options that I can see. The survey lib which powers the options selector exposes a WithValidator hook which we could implement?

AFAIR There were some problems with testing select input as survey always picked the first item on the list, hence no tests were implemented.

Anyway, if CLI and UI depend on backend validation here, then user will be warned about value conflict. If you want to try, you can modify cli/update_test.go to address the monotonicity use case, but I'm also cool if it is hard/impossible to do 👍

[dannykopping]

cli/update_test.go

Will do, thanks!

[dannykopping]

cli/update_test.go

Will do, thanks!

@mtojek I added a test in aae5463, PTAL?

I also updated the provider now that coder/terraform-provider-coder#202 is merged.

[mtojek]

One nit pick to clarify (restart or update) but otherwise it is 👍 .