Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://coder.com/docs/admin/templates/extending-templates/dynamic-parameters below:

Dynamic Parameters | Coder Docs

Coder v2.24.0 introduces Dynamic Parameters to extend Coder parameters with conditional form controls, enriched input types, and user identity awareness. This allows template authors to create interactive workspace creation forms with more environment customization, and that means fewer templates to maintain.

All parameters are parsed from Terraform, so your workspace creation forms live in the same location as your provisioning code. You can use all the native Terraform functions and conditionality to create a self-service tooling catalog for every template.

Administrators can use Dynamic Parameters to:

• Create parameters which respond to the inputs of others.
• Only show parameters when other input criteria are met.
• Only show select parameters to target Coder roles or groups.

You can try the Dynamic Parameter syntax and any of the code examples below in the Parameters Playground. You should experiment with parameters in the playground before you upgrade live templates.

While Dynamic parameters introduce a variety of new powerful tools, all functionality is backwards compatible with existing coder templates. When you opt-in to the new experience, no functional changes will be applied to your production parameters.

Some reasons Coder template admins should try Dynamic Parameters:

• You maintain or support many templates for teams with unique expectations or use cases.
• You want to selectively expose privileged workspace options to admins, power users, or personas.
• You want to make the workspace creation flow more ergonomic for developers.

Dynamic Parameters help you reduce template duplication by setting the conditions for which users should see specific parameters. They reduce the potential complexity of user-facing configuration by allowing administrators to organize a long list of options into interactive, branching paths for workspace customization. They allow you to set resource guardrails by referencing Coder identity in the coder_workspace_owner data source.

In Coder v2.25.0, Dynamic Parameters are automatically enabled for new templates. You can opt-in to Dynamic Parameters for individual existing templates via template settings.

1. Go to your template's settings and enable the Enable dynamic parameters for workspace creation option.

2. Update your template to use version >=2.4.0 of the Coder provider with the following Terraform block.

   terraform { required_providers { coder = { source = "coder/coder" version = ">=2.4.0" } } }

3. This enables Dynamic Parameters in the template. Add some conditional parameters.

   Note that these new features must be declared in your Terraform to start leveraging Dynamic Parameters.

4. Save and publish the template.

5. Users should see the updated workspace creation form.

Dynamic Parameters features are backwards compatible, so all existing templates may be upgraded in-place. If you decide to revert to the legacy flow later, disable Dynamic Parameters in the template's settings.

Dynamic Parameters introduces three primary enhancements to the standard parameter system:

• Conditional Parameters

  • Parameters can respond to changes in other parameters
  • Show or hide parameters based on other selections
  • Modify validation rules conditionally
  • Create branching paths in workspace creation forms

• Reference User Properties

  • Read user data at build time from coder_workspace_owner
  • Conditionally hide parameters based on user's role
  • Change parameter options based on user groups
  • Reference user name, groups, and roles in parameter text

• Additional Form Inputs

  • Searchable dropdown lists for easier selection
  • Multi-select options for choosing multiple items
  • Secret text inputs for sensitive information
  • Slider input for disk size, model temperature
  • Disabled parameters to display immutable data

Important

Dynamic Parameters does not support external data fetching via HTTP endpoints at workspace build time.

External fetching would introduce unpredictability in workspace builds after publishing a template. Instead, we recommend that template administrators pull in any required data for a workspace build as a locals or JSON file, then reference that data in Terraform.

If you have a use case for external data fetching, please file an issue or create a discussion in the Coder GitHub repository.

Dynamic Parameters supports a variety of form types to create rich, interactive user experiences.

Different parameter types support different form types. You can specify the form type using the form_type attribute.

The Options column in the table below indicates whether the form type supports options (Yes) or doesn't support them (No). When supported, you can specify options using one or more option blocks in your parameter definition, where each option has a name (displayed to the user) and a value (used in your template logic).

The coder_parameter resource supports an additional styling attribute for special cosmetic changes that can be used to further customize the workspace creation form.

This can be used for:

• Masking private inputs
• Marking inputs as read-only
• Setting placeholder text

Note that the styling attribute should not be used as a governance tool, since it only changes how the interactive form is displayed. Users can avoid restrictions like disabled if they create a workspace via the CLI.

This attribute accepts JSON like so:

data "coder_parameter" "styled_parameter" { ... styling = jsonencode({ disabled = true }) }

Not all styling attributes are supported by all form types, use the reference below for syntax:

The following examples show some basic usage of the form_type attribute explained above. These are used to change the input style of form controls in the create workspace form.

Single-select parameters with options can use the form_type="dropdown" attribute for better organization.

Try dropdown lists on the Parameter Playground

locals { ides = [ "VS Code", "JetBrains IntelliJ", "PyCharm", "GoLand", "WebStorm", "Vim", "Emacs", "Neovim" ] } data "coder_parameter" "ides_dropdown" { name = "ides_dropdown" display_name = "Select your IDEs" type = "string" form_type = "dropdown" dynamic "option" { for_each = local.ides content { name = option.value value = option.value } } }

Using native Terraform syntax and parameter attributes like count, we can allow some parameters to react to user inputs.

This means:

• Hiding parameters unless activated
• Conditionally setting default values
• Changing available options based on other parameter inputs

Use these in conjunction to build intuitive, reactive forms for workspace creation.

Use Terraform conditionals and the count block to allow a checkbox to expose or hide a subsequent parameter.

Try conditional parameters on the Parameter Playground.

data "coder_parameter" "show_cpu_cores" { name = "show_cpu_cores" display_name = "Toggles next parameter" description = "Select this checkbox to show the CPU cores parameter." type = "bool" form_type = "checkbox" default = false order = 1 } data "coder_parameter" "cpu_cores" { # Only show this parameter if the previous box is selected. count = data.coder_parameter.show_cpu_cores.value ? 1 : 0 name = "cpu_cores" display_name = "CPU Cores" type = "number" form_type = "slider" default = 2 order = 2 validation { min = 1 max = 8 } }

Premium users can leverage our roles and groups to conditionally expose or change parameters based on user identity. This is helpful for establishing governance policy directly in the workspace creation form, rather than creating multiple templates to manage RBAC.

User identity is referenced in Terraform by reading the coder_workspace_owner data source.

Template administrators often want to expose certain experimental or unstable options only to those with elevated roles. You can now do this by setting count based on a user's group or role, referencing the coder_workspace_owner data source.

Try out admin-only options in the Playground.

locals { roles = [for r in data.coder_workspace_owner.me.rbac_roles: r.name] is_admin = contains(data.coder_workspace_owner.me.groups, "admin") has_admin_role = contains(local.roles, "owner") } data "coder_workspace_owner" "me" {} data "coder_parameter" "advanced_settings" { # This parameter is only visible when the user is an administrator count = local.is_admin ? 1 : 0 name = "advanced_settings" display_name = "Add an arbitrary script" description = "An advanced configuration option only available to admins." type = "string" form_type = "textarea" mutable = true order = 5 styling = jsonencode({ placeholder = <<-EOT #!/usr/bin/env bash while true; do echo "hello world" sleep 1 done EOT }) }

Dynamic Parameters is now in general availability. We're tracking a list of known issues here in Github as we continue to polish and improve the workflow. If you have any issues during upgrade, please file an issue in our GitHub repository with the parameters label and include a Playground link where applicable. We appreciate the feedback and look forward to what the community creates with this system!

You can also search or track the list of known issues.

You can share anything you build with Dynamic Parameters in our Discord.

Ensure that the following version requirements are met:

• coder/coder: >= v2.25.0
• coder/terraform-provider-coder: >= v2.5.3

Enabling Dynamic Parameters on an existing template requires administrators to publish a new template version. This will resolve the necessary template metadata to render the form.

To revert Dynamic Parameters on a template:

1. Prepare your template by removing any conditional logic or user data references in parameters.

2. As a template administrator or owner, go to your template's settings:

   Templates > Your template > Settings

3. Uncheck the Enable dynamic parameters for workspace creation option.

4. Create a new template version and publish to the active version.

Dynamic Parameters is GA as of v2.25.0, and this issue has been resolved. In beta (v2.24.0), template variables were not supported in Dynamic Parameters.

If you are experiencing issues with template variables, try upgrading to the latest version with dynamic parameters in GA. Otherwise, please file an issue in our Github.

Yes, registry modules are supported with Dynamic Parameters.

Unless explicitly mentioned, no registry modules require Dynamic Parameters. Later in 2025, more registry modules will be converted to Dynamic Parameters to improve their UX.

In the meantime, you can safely convert existing templates and build new parameters on top of the functionality provided in the registry.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4