mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
Normalizes non-standard code-fence language tags across `docs/**` so a strict highlighter (Shiki, used by Fumadocs) won't fail the build on an unrecognized language, and unifies redundant synonym tags onto one canonical form per language. The current renderer (Speed-Highlight) detects the language from the code content, not the fence label, so this drift wasn't visible until now. ## Changes - `hcl` -> `tf` (199 fences, including indented ones nested in numbered/bulleted lists). Shiki ships `hcl` and `terraform` as two distinct grammars (not aliases); every `hcl`-tagged fence in `docs/**` is actually Terraform resource/data/provider syntax, so the more specific `terraform` grammar is correct for all of them. `tf` is Shiki's own alias for that grammar, and it's also what GitHub's own markdown renderer resolves to the same HCL/Terraform highlighting. - `pwsh`/`powershell` -> `ps1`. Both `ps` and `ps1` are registered PowerShell aliases in Shiki, but on GitHub's renderer only `.ps1` is a registered file extension (`.ps` isn't), so `ps1` renders identically to `powershell` there today while bare `ps` would silently lose highlighting. - `env` -> `dotenv` (a dedicated Shiki grammar for `KEY=VALUE` files) - `text`/`output`/`none`/`url` -> `txt`. Same built-in plain-text fallback either way, just shorter. - `Dockerfile` -> `dockerfile` (lowercase) - `bash`/`shell` -> `sh` (732 fences). Shiki and GitHub both alias all three to a single shell grammar; this was already the style guide's stated preference, just not enforced across the existing corpus until now. - `markdown` -> `md` (4 fences). Alias of the same grammar in both Shiki and GitHub. - `jsonc` -> `json` (1 fence). The block has no comments or trailing commas, so it doesn't need the comments-capable grammar. - `ts` -> `tsx` (2 fences, `docs/about/contributing/frontend.md`). Verified the actual content tokenizes identically under both grammars, and a sibling block in the same file already needs `tsx` for real JSX, so unifying to one tag is safe for this file. Documented a caveat: `tsx` mis-tokenizes the legacy angle-bracket type-assertion syntax (`<Type>value`), which is invalid in real `.tsx` files anyway, so use `value as Type` instead. - `yml` -> `yaml` (1 fence) - Updated `docs/.style/style-guide/formatting.md` to document all canonical tags `promql` (2 fences) and `caddyfile` (2 fences) are left as-is. Shiki doesn't bundle a grammar for either, so they need a custom grammar registration when the site adopts Shiki, rather than degrading to `txt`. Tracked as follow-up work under DOCS-118 and [DOCS-544](https://linear.app/codercom/issue/DOCS-544/vendor-a-local-promql-grammar-for-shiki-syntax-highlighting) (promql). Does not touch `offlinedocs/`. Linear: [DOCS-476](https://linear.app/codercom/issue/DOCS-476/normalize-docs-code-fence-languages-de-risk-shikifumadocs) <details> <summary>How the fence tags were verified</summary> Each tag was tested against a real `shiki@latest` highlighter instance (`codeToHtml`/`codeToTokens`) and cross-checked against GitHub's `@wooorm/starry-night` grammar sources (the renderer that actually displays these `.md` files today, in repo browsing and PR diffs), since that's what determines whether brevity is safe before Shiki adoption: ```text FAIL env -- Language `env` is not included in this bundle. FAIL Dockerfile -- Language `Dockerfile` is not included in this bundle. FAIL promql -- Language `promql` is not included in this bundle. FAIL caddyfile -- Language `caddyfile` is not included in this bundle. FAIL pwsh -- Language `pwsh` is not included in this bundle. FAIL output -- Language `output` is not included in this bundle. ``` `hcl` doesn't error in Shiki, since it's a real grammar, but that's exactly the trap: it was silently rendering every fence with the generic HCL grammar instead of the Terraform-specific one. Every `hcl`-tagged fence in `docs/**` was manually checked against `origin/main` and is genuinely Terraform content. For `ts`/`tsx`, tokenizing the actual doc content confirmed identical output under both grammars; a synthetic test with the legacy angle-bracket cast syntax confirmed `tsx` degrades on that specific construct, which the style guide now calls out. The first normalization pass only matched fence tags at column 0 (`^```tag$`), missing tags indented inside numbered/bulleted lists. A follow-up pass caught the remaining occurrences at any indentation level. </details> --- *This PR description and the underlying changes were prepared with Coder Agents assistance.*
135 lines
5.6 KiB
Markdown
135 lines
5.6 KiB
Markdown
# Add an Envbuilder template
|
|
|
|
A Coder administrator adds an Envbuilder-compatible template to Coder. This
|
|
allows the template to prompt the developer for their dev container repository's
|
|
URL as a [parameter](../../../templates/extending-templates/parameters.md) when they create
|
|
their workspace. Envbuilder clones the repo and builds a container from the
|
|
`devcontainer.json` specified in the repo.
|
|
|
|
You can create template files through the Coder dashboard, CLI, or you can
|
|
choose a template from the
|
|
[Coder registry](https://registry.coder.com/templates):
|
|
|
|
<div class="tabs">
|
|
|
|
## Dashboard
|
|
|
|
1. In the Coder dashboard, select **Templates** > **New Template**.
|
|
The template builder opens.
|
|
1. The template builder does not currently include dev-container-compatible base templates.
|
|
Select **Upload an existing template** at the bottom of the page to upload your Terraform files directly.
|
|
1. Upload your `.zip` or `.tar.gz` file, enter the details, then select **Create template**.
|
|
1. Edit the template files to fit your deployment.
|
|
|
|
## CLI
|
|
|
|
1. Use the `template init` command to initialize your choice of image:
|
|
|
|
```sh
|
|
coder template init --id kubernetes-devcontainer
|
|
```
|
|
|
|
A list of available templates is shown in the
|
|
[templates_init](../../../../reference/cli/templates.md) reference.
|
|
|
|
1. `cd` into the directory and push the template to your Coder deployment:
|
|
|
|
```sh
|
|
cd kubernetes-devcontainer && coder templates push
|
|
```
|
|
|
|
You can also edit the files or make changes to the files before you push them
|
|
to Coder.
|
|
|
|
## Registry
|
|
|
|
1. Go to the [Coder registry](https://registry.coder.com/templates) and select a
|
|
dev container-compatible template.
|
|
|
|
1. Copy the files to your local device, then edit them to fit your needs.
|
|
|
|
1. Upload them to Coder through the CLI or dashboard:
|
|
|
|
- CLI:
|
|
|
|
```sh
|
|
coder templates push <template-name> -d <path to folder containing main.tf>
|
|
```
|
|
|
|
- Dashboard:
|
|
|
|
1. Create a `.zip` of the template files:
|
|
|
|
- On Mac or Windows, highlight the files and then right click. A
|
|
"compress" option is available through the right-click context menu.
|
|
|
|
- To zip the files through the command line:
|
|
|
|
```sh
|
|
zip templates.zip Dockerfile main.tf
|
|
```
|
|
|
|
1. Select **Templates**.
|
|
1. Select **Create Template**, then **Upload template**:
|
|
|
|

|
|
|
|
1. Drag the `.zip` file into the **Upload template** section and fill out the
|
|
details, then select **Create template**.
|
|
|
|

|
|
|
|
</div>
|
|
|
|
To set variables such as the namespace, go to the template in your Coder
|
|
dashboard and select **Settings** from the **⋮** (vertical ellipsis) menu:
|
|
|
|
<Image height="255px" src="../../../../images/templates/template-menu-settings.png" alt="Choose Settings from the template's menu" align="center" />
|
|
|
|
## Envbuilder Terraform provider
|
|
|
|
When using the
|
|
[Envbuilder Terraform provider](https://registry.terraform.io/providers/coder/envbuilder/latest/docs),
|
|
a previously built and cached image can be reused directly, allowing dev
|
|
containers to start instantaneously.
|
|
|
|
Developers can edit the `devcontainer.json` in their workspace to customize
|
|
their development environments:
|
|
|
|
```json
|
|
# …
|
|
{
|
|
"features": {
|
|
"ghcr.io/devcontainers/features/common-utils:2": {}
|
|
}
|
|
}
|
|
# …
|
|
```
|
|
|
|
## Example templates
|
|
|
|
| Template | Description |
|
|
|-------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| [Docker dev containers](../../../../../examples/templates/docker-devcontainer) | Docker provisions a development container. |
|
|
| [Kubernetes dev containers](../../../../../examples/templates/kubernetes-devcontainer) | Provisions a development container on the Kubernetes cluster. |
|
|
| [Google Compute Engine dev container](../../../../../examples/templates/gcp-devcontainer) | Runs a development container inside a single GCP instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
|
| [AWS EC2 dev container](../../../../../examples/templates/aws-devcontainer) | Runs a development container inside a single EC2 instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
|
|
|
Your template can prompt the user for a repo URL with
|
|
[parameters](../../../templates/extending-templates/parameters.md):
|
|
|
|

|
|
|
|
## Dev container lifecycle scripts
|
|
|
|
The `onCreateCommand`, `updateContentCommand`, `postCreateCommand`, and
|
|
`postStartCommand` lifecycle scripts are run each time the container is started.
|
|
This could be used, for example, to fetch or update project dependencies before
|
|
a user begins using the workspace.
|
|
|
|
Lifecycle scripts are managed by project developers.
|
|
|
|
## Next steps
|
|
|
|
- [Envbuilder security and caching](./envbuilder-security-caching.md)
|