mirror of
https://github.com/coder/coder.git
synced 2026-11-02 05:23:10 +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.*
141 lines
4.2 KiB
Markdown
141 lines
4.2 KiB
Markdown
# Open in Coder
|
|
|
|
You can embed an "Open in Coder" button into your git repos or internal wikis to
|
|
let developers quickly launch a new workspace.
|
|
|
|
<video autoplay playsinline loop>
|
|
<source src="../../images/templates/open-in-coder.mp4?raw=true" type="video/mp4">
|
|
Your browser does not support the video tag.
|
|
</video>
|
|
|
|
## How it works
|
|
|
|
To support any infrastructure and software stack, Coder provides a generic
|
|
approach for "Open in Coder" flows.
|
|
|
|
### 1. Set up git authentication
|
|
|
|
See [External Authentication](../external-auth/index.md) to set up Git authentication
|
|
in your Coder deployment.
|
|
|
|
### 2. Modify your template to auto-clone repos
|
|
|
|
The id in the template's `coder_external_auth` data source must match the
|
|
`CODER_EXTERNAL_AUTH_X_ID` in the Coder deployment configuration.
|
|
|
|
If you want the template to clone a specific git repo:
|
|
|
|
```tf
|
|
# Require external authentication to use this template
|
|
data "coder_external_auth" "github" {
|
|
id = "primary-github"
|
|
}
|
|
|
|
resource "coder_agent" "dev" {
|
|
# ...
|
|
dir = "~/coder"
|
|
startup_script =<<EOF
|
|
|
|
# Clone repo from GitHub
|
|
if [ ! -d "coder" ]
|
|
then
|
|
git clone https://github.com/coder/coder
|
|
fi
|
|
|
|
EOF
|
|
}
|
|
```
|
|
|
|
> [!NOTE]
|
|
> The `dir` attribute can be set in multiple ways, for example:
|
|
>
|
|
> - `~/coder`
|
|
> - `/home/coder/coder`
|
|
> - `coder` (relative to the home directory)
|
|
|
|
If you want the template to support any repository via
|
|
[parameters](./extending-templates/parameters.md)
|
|
|
|
```tf
|
|
# Require external authentication to use this template
|
|
data "coder_external_auth" "github" {
|
|
id = "primary-github"
|
|
}
|
|
|
|
# Prompt the user for the git repo URL
|
|
data "coder_parameter" "git_repo" {
|
|
name = "git_repo"
|
|
display_name = "Git repository"
|
|
default = "https://github.com/coder/coder"
|
|
}
|
|
|
|
locals {
|
|
folder_name = try(element(split("/", data.coder_parameter.git_repo.value), length(split("/", data.coder_parameter.git_repo.value)) - 1), "")
|
|
}
|
|
|
|
resource "coder_agent" "dev" {
|
|
# ...
|
|
dir = "~/${local.folder_name}"
|
|
startup_script =<<EOF
|
|
|
|
# Clone repo from GitHub
|
|
if [ ! -d "${local.folder_name}" ]
|
|
then
|
|
git clone ${data.coder_parameter.git_repo.value}
|
|
fi
|
|
|
|
EOF
|
|
}
|
|
```
|
|
|
|
### 3. Embed the "Open in Coder" button with Markdown
|
|
|
|
```md
|
|
[](https://YOUR_ACCESS_URL/templates/YOUR_TEMPLATE/workspace)
|
|
```
|
|
|
|
Be sure to replace `YOUR_ACCESS_URL` with your Coder access url (e.g.
|
|
<https://coder.example.com>) and `YOUR_TEMPLATE` with the name of your template.
|
|
|
|
### 4. Optional: pre-fill parameter values in the "Create Workspace" page
|
|
|
|
This can be used to pre-fill the git repo URL, disk size, image, etc.
|
|
|
|
```md
|
|
[](https://YOUR_ACCESS_URL/templates/YOUR_TEMPLATE/workspace?param.git_repo=https://github.com/coder/slog¶m.home_disk_size%20%28GB%29=20)
|
|
```
|
|
|
|

|
|
|
|
### 5. Optional: disable specific parameter fields by including their names as
|
|
|
|
specified in your template in the `disable_params` search params list
|
|
|
|
```md
|
|
[](https://YOUR_ACCESS_URL/templates/YOUR_TEMPLATE/workspace?disable_params=first_parameter,second_parameter)
|
|
```
|
|
|
|
### Security: consent dialog for automatic creation
|
|
|
|
When using `mode=auto` with prefilled `param.*` values, Coder displays a
|
|
security consent dialog before creating the workspace. This protects users
|
|
from malicious links that could provision workspaces with untrusted
|
|
configurations, such as dotfiles or startup scripts from unknown sources.
|
|
|
|
The dialog shows:
|
|
|
|
- A warning that a workspace is about to be created automatically from a link
|
|
- All prefilled `param.*` values from the URL
|
|
- **Confirm and Create** and **Cancel** buttons
|
|
|
|
The workspace is only created if the user explicitly clicks **Confirm and
|
|
Create**. Clicking **Cancel** falls back to the standard creation form where
|
|
all parameters can be reviewed manually.
|
|
|
|

|
|
|
|
### Example: Kubernetes
|
|
|
|
For a full example of the Open in Coder flow in Kubernetes, check out
|
|
[this example template](https://github.com/bpmct/coder-templates/tree/main/kubernetes-open-in-coder).
|