## Summary High-confidence textual subset of the DOCS-637 **P2/P3** drift batch (31 findings total). These 8 fixes are pure typo / grammar / syntax corrections verified directly against the doc source, so they carry no risk of misreconstructed command output. ## Changes (6 files) | Page | Fix | |------|-----| | `docs/admin/templates/extending-templates/variables.md` | Remove doubled word: "file in in the template directory" → "file in the template directory". | | `docs/admin/networking/port-forwarding.md` | Grammar: heading "From an coder_app resource" → "From a coder_app resource". | | `docs/user-guides/workspace-access/index.md` | Malformed heading "Through with the CLI" → "Through the CLI". | | `docs/about/contributing/modules.md` | Conventional-commit example missing the required space: `feat(git-clone):add` → `feat(git-clone): add`. | | `docs/ai-coder/tasks-migration.md` | Add missing closing double-quotes on Terraform `source`/`version` in two snippets that would fail `terraform` parsing. | | `docs/admin/users/idp-sync.md` | Role Sync section said "group sync settings" (copy-paste from the Group Sync section); remove an invalid trailing comma from a JSON output example. | ## Deferred (remaining ~23 P2/P3 items, not in this PR) The rest of the batch is stale **command-output** samples (column/schema changes, sample values) and items that need a content decision (e.g. `--psk` now deprecated in favor of `--key`; `--address` deprecated; an undocumented retention flag). Those need live-output reconstruction or a call on direction, so they're left for follow-up work, consistent with the issue's "handle after the P0/P1 fixes land" guidance. One catalog row (`reverse-proxy-nginx.md:57`, certbot `ws=apache`) is already handled by #28086 and is excluded here. Linear: https://linear.app/codercom/issue/DOCS-646 > This PR was created with AI assistance (Coder Agents).
5.2 KiB
Terraform template-wide variables
In Coder, Terraform templates offer extensive flexibility through template-wide variables. These variables, managed by template authors, facilitate the construction of customizable templates. Unlike parameters, which are primarily for workspace customization, template variables remain under the control of the template author, ensuring workspace users cannot modify them.
variable "CLOUD_API_KEY" {
type = string
description = "API key for the service"
default = "1234567890"
sensitive = true
}
Given that variables are a
fundamental concept in Terraform,
Coder endeavors to fully support them. Native support includes string,
number, and bool formats. However, other types such as list(string) or
map(any) will default to being treated as strings.
Default value
Upon adding a template variable, it's mandatory to provide a value during the first push. At this stage, the template administrator faces two choices:
- No
defaultproperty: opt not to define a default property. Instead, utilize the--var name=valuecommand-line argument during the push to supply the variable's value. - Define
defaultproperty: set a default property for the template variable. If the administrator doesn't input a value via CLI, Coder automatically uses this default during the push.
After the initial push, variables are stored in the database table, associated with the specific template version. They can be conveniently managed via Template Settings without requiring an extra push.
Resolved values vs. default values
It's crucial to note that Coder templates operate based on resolved values during a push, rather than default values. This ensures that default values do not inadvertently override the configured variable settings during the push process.
This approach caters to users who prefer to avoid accidental overrides of their variable settings with default values during pushes, thereby enhancing control and predictability.
If you encounter a situation where you need to override template settings for variables, you can employ a straightforward solution:
-
Create a
terraform.tfvarsfile in the template directory:coder_image = newimage:tag -
Push the new template revision using Coder CLI:
coder templates push my-template -y # no need to use --var
This file serves as a mechanism to override the template settings for variables. It can be stored in the repository for easy access and reference. Coder CLI automatically detects it and loads variable values.
Input options
When working with Terraform configurations in Coder, you have several options for providing values to variables using the Coder CLI:
- Manual input in CLI: You can manually input values for Terraform variables directly in the CLI during the deployment process.
- Web UI: You can set or edit variable values under Variables in the template's settings.
- Command-line argument: Utilize the
--var name=valuecommand-line argument to specify variable values inline as key-value pairs. - Variables file selection: Alternatively, you can use a variables file
selected via the
--variables-file values.ymlcommand-line argument. This approach is particularly useful when dealing with multiple variables or to avoid manual input of numerous values. Variables files can be versioned for better traceability and management, and it enhances reproducibility.
Here's an example of a YAML-formatted variables file, values.yml:
region: us-east-1
bucket_name: magic
zone_types: '{"us-east-1":"US East", "eu-west-1": "EU West"}'
cpu: 1
In this sample file:
region,bucket_name,zone_types, andcpuare Terraform variable names.- Corresponding values are provided for each variable.
- The
zone_typesvariable demonstrates how to provide a JSON-formatted string as a value in YAML.
Terraform .tfvars files
In Terraform, .tfvars files provide a convenient means to define variable
values for a project in a reusable manner. These files, ending with either
.tfvars or .tfvars.json, streamline the process of setting numerous
variables.
By utilizing .tfvars files, you can efficiently manage and organize variable
values for your Terraform projects. This approach offers several advantages:
- Clarity and consistency: Centralize variable definitions in dedicated files, enhancing clarity, instead of input values on template push.
- Ease of maintenance: Modify variable values in a single location under version control, simplifying maintenance and updates.
Coder automatically loads variable definition files following a specific order, providing flexibility and control over variable configuration. The loading sequence is as follows:
terraform.tfvars: This file contains variable values and is loaded first.terraform.tfvars.json: If present, this JSON-formatted file is loaded afterterraform.tfvars.\*.auto.tfvars: Files matching this pattern are loaded next, ordered alphabetically.\*.auto.tfvars.json: JSON-formatted files matching this pattern are loaded last.