## Summary
GCP base templates (`gcp-linux`, `gcp-windows`) in the Template Builder
had a Terraform `variable "project_id"` with no default, but their
`base.json` manifests didn't declare it. The UI never prompted for it,
so the provisioner import always failed with:
```
required template variables need values: project_id
```
## Changes
- Add `project_id` as a required variable in both GCP `base.json`
manifests
- Convert templates from raw Terraform variable blocks to Go template
injection (`{{ .Variables.project_id }}`), matching the existing
kubernetes pattern
- Fix `DefaultBaseRenderContext` to supply a `"REQUIRED"` placeholder
for required variables without defaults (previously rendered as `<no
value>`)
- Replace duplicate test subtests with proper GCP coverage including a
missing-variable error case
<details>
<summary>Implementation plan</summary>
### Root cause
The GCP base templates contained `variable "project_id" {}` (no default
= required) in their `.tf.tmpl` files, but the `base.json` manifests had
an empty `variables` array. The Template Builder UI
(`BaseTemplateParametersStep`) is data-driven from `base.json`, so it
never showed a field for `project_id`. The composed Terraform output
still contained the required variable, causing the provisioner import to
fail.
### Fix approach
Follow the pattern established by the kubernetes base template:
1. Declare variables in `base.json` so the UI prompts for them
2. Use Go template syntax (`{{ .Variables.project_id }}`) to inject
values at compose time
3. Remove raw Terraform `variable` blocks from the template since the
value is now baked in
### Files changed
| File | Change |
|---|---|
| `bases/gcp-linux/base.json` | Added `project_id` as a required
variable |
| `bases/gcp-windows/base.json` | Added `project_id` as a required
variable |
| `bases/gcp-linux/main.tf.tmpl` | Removed Terraform variable block, use
Go template injection |
| `bases/gcp-windows/main.tf.tmpl` | Same |
| `bases.go` | `DefaultBaseRenderContext` supplies placeholder for
required vars without defaults |
| `compose_test.go` | Replaced duplicate subtests with proper GCP tests
|
| `templatebuilder_handler_test.go` | Updated `gcp-windows` spec to
expect `project_id` variable |
| Golden files | Regenerated |
</details>
> 🤖 Generated by Coder Agents on behalf of @jeremyruppel
display_name, description, icon, maintainer_github, verified, tags
| display_name | description | icon | maintainer_github | verified | tags | |||
|---|---|---|---|---|---|---|---|---|
| Google Compute Engine (Linux) | Provision Google Compute Engine instances as Coder workspaces | ../../../site/static/icon/gcp.png | coder | true |
|
Remote Development on Google Compute Engine (Linux)
Prerequisites
Authentication
This template assumes that coderd is run in an environment that is authenticated
with Google Cloud. For example, run gcloud auth application-default login to
import credentials on the system and user running coderd. For other ways to
authenticate consult the Terraform
docs.
Coder requires a Google Cloud Service Account to provision workspaces. To create a service account:
-
Navigate to the CGP console, and select your Cloud project (if you have more than one project associated with your account)
-
Provide a service account name (this name is used to generate the service account ID)
-
Click Create and continue, and choose the following IAM roles to grant to the service account:
- Compute Admin
- Service Account User
Click Continue.
-
Click on the created key, and navigate to the Keys tab.
-
Click Add key > Create new key.
-
Generate a JSON private key, which will be what you provide to Coder during the setup process.
Architecture
This template provisions the following resources:
- GCP VM (ephemeral)
- GCP Disk (persistent, mounted to root)
Coder persists the root volume. The full filesystem is preserved when the workspace restarts. See this community example of an ephemeral AWS instance.
Note
This template is designed to be a starting point! Edit the Terraform to extend the template to support your use case.