Problem

Currently parameters have some ambiguity around how they are supposed to behave.

• Parameters currently act in a hierarchy:workspace > version > template.
• The prompting for params depends on thesensitive field of the terraform variable.
• Parameter scopetemplate is unused in the codebase.
• Parameter scopeimport_job is associated with a job, but should probably be tied to a template_version

CLI prompts for new params and handles deleted params in a new version, but the UI does not. The decision tree for how to handle param prompting is complex.

• Do param files override previous version values?
• Should param files require all values? Just new values?
• UI has to copy the cli behavior

CLI param handling code is unique for template flow and workspace flow. We should unify this logic.

• What if workspace sets a "sensitive" value?

Who can read param values? Secret values?

How to inherit params from previous version/workspace build?

Design

A design document for params should be created on how params should function. From the terraform value, to the database store, to how to fill in param values. The terraform fileshould be able to indicate where values should be prompted (at the version create or workspace create)

A good parameter viewer to indicate which param values are associated with a version/workspace and where they came from. Maybe an editor to change these values??

Should we keep a param hierarchy? Or should some values be required to be set at a certain scope, and disallow workspaces from setting them?

Prompt for missing params does not cleanup broken template versions.

Acceptance Criteria

• Design doc detailing how to use params as a developer and as a user
• ???