Relates to #15047

Motivation

Provisioner daemons can expose a set of tags [1] that allow Coder administrators to control the context in which a workspace or template job are evaluated. When creating a template version import job or workspace build job, users can manually specify a set of tags to be applied to the job as part of the request.

These tags are normally evaluated in coderd/wsbuilder.

The coder_workspace_tags [2] data source allows users to specify provisioner tags for workspaces built from a given template.

Example:

data "coder_workspace_tags" "custom_workspace_tags" {
  tags = {
    "zone"        = "developers"
    "runtime"     = data.coder_parameter.runtime_selector.value
    "project_id"  = "PROJECT_${data.coder_parameter.project_name.value}"
    "cache"       = data.coder_parameter.feature_cache_enabled.value == "true" ? "with-cache" : "no-cache"
  }
}

While investigating #15047 we noticed an issue whereby a template import job would appear to 'hang'. This turned out to be due to the template specifying a set of tags in the HCL but not having any suitably tagged provisioners available. There is an inherent chicken and egg problem here, as Coder would need to run the job to determine the tag values, but needs the tag values to schedule the job.

Additionally, we also noted an issue where users could specify potentially mutable / variable data sources as a value source for coder_workspace_tags.
Example:

data "coder_workspace_tags" "custom_workspace_tags" {
  tags = {
    "runtime"     = data.env_var.runtime.value # using some provider that reads environment variables
  }
}

The value of that environment variable is not guaranteed to resolve to the same value, depending on what provisioner is running the job.

Proposed Solution

1. Add a pre-flight check when importing a template. This will involve parsing the Terraform files provided, checking for any declarations of coder_workspace_tags, and validating that the values for each key resolve to either:

• A static variable ("developers")
• A template-level variable (var.az)
• A coder parameter (data.coder_parameter.foo.value)

Any other data sources for workspace tags should cause a large warning on the potential ramifications of this block the template import job as the required data sources will not be available. We could also block a template version import but that runs the risk of blocking a critical path for a hypothetical problem.

As a side-effect, the pre-flight check can also automatically set the provisioner tags it discovers on the provisioner job.

[1] https://coder.com/docs/admin/templates/extending-templates/workspace-tags
[2] https://registry.terraform.io/providers/coder/coder/latest/docs/data-sources/workspace_tags