Administrators use coder_parameters to provide developers configuration options that may vary between workspaces on the same template. These are often used to set resource values, instance types, host regions, or IDEs to inject as coder_apps.

The state of these parameters must be determined at template build time. Administrators must define all options for a parameter well before a user creates their workspace using it. This causes difficulty for administrators as the resources referenced by a coder_parameter may be dynamic. For example, adding an "instance type" parameter expects admins to manually hard-code all instance types for the template, then force users to select an option compatible with their region. This can be a functional blocker on workspace creation and a management burden on administrators.

Additionally, other CDE solutions allow the typical use-case of listing all Github repositories that belong to a user to clone when creating an environment. Pairing a parameter that can dynamically list Github repositories with our git-clone module would achieve feature parity.

Solution proposal

Note: This feature is still being designed. Implementation and UX are subject to change.

We will improve this workflow by allowing parameters to fetch data dynamically upon workspace build. This data can be retrieved from any API endpoint and be used to populate any of our parameter types. Our initial design adds a coder_parameter_source to fetch the API at build time.

data "coder_parameter_source" "org-projects" {
  get = "https://github.com/orgs/${data.coder_parameter.organization}/repos" 
  body {
    user = data.coder_workspace.me.owner # Not actually valid for this call; just an example.
  }
  headers {
    X-FOO = "bar"
  }
}
data "coder_parameter" "projects" {
  name = "Select projects to clone"
  default = element(data.coder_parameter_source.org-projects, 0)
  option = [for repo in data.coder_paramater_source.org-projects : {
	  value = repo.url
  }]
}