mirror of
https://github.com/coder/coder.git
synced 2026-09-22 05:05:20 +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.*
4.1 KiB
4.1 KiB
Test and Publish Coder Templates Through CI/CD
November 15, 2024Overview
This guide demonstrates how to test and publish Coder templates in a Continuous Integration (CI) pipeline using the coder/setup-action. This workflow ensures your templates are validated, tested, and promoted seamlessly.
Prerequisites
- Install and configure Coder CLI in your environment.
- Install Terraform CLI in your CI environment.
- Create a headless user with the user roles and permissions to manage templates and run workspaces.
Creating the headless user
Warning
Creating users with
--login-type noneis deprecated. For Premium deployments, use service accounts instead. For OSS deployments, use a regular account with password, GitHub, or OIDC authentication.
For Premium deployments, create a service account:
coder users create \
--username machine-user \
--service-account
coder tokens create --user machine-user --lifetime 8760h
# Copy the token and store it in a secret in your CI environment with the name `CODER_SESSION_TOKEN`
For OSS deployments, create a regular user:
coder users create \
--username machine-user \
--email machine-user@example.com \
--login-type password
coder tokens create --user machine-user --lifetime 8760h
# Copy the token and store it in a secret in your CI environment with the name `CODER_SESSION_TOKEN`
Example GitHub Action Workflow
This example workflow tests and publishes a template using GitHub Actions.
The workflow:
- Validates the Terraform template.
- Pushes the template to Coder without activating it.
- Tests the template by creating a workspace.
- Promotes the template version to active upon successful workspace creation.
Workflow File
Save the following workflow file as .github/workflows/publish-template.yaml in
your repository:
name: Test and Publish Coder Template
on:
push:
branches:
- main
workflow_dispatch:
jobs:
test-and-publish:
runs-on: ubuntu-latest
env:
TEMPLATE_NAME: "my-template"
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Terraform
uses: hashicorp/setup-terraform@v2
with:
terraform_version: latest
- name: Set up Coder CLI
uses: coder/setup-action@v1
with:
access_url: "https://coder.example.com"
coder_session_token: ${{ secrets.CODER_SESSION_TOKEN }}
- name: Validate Terraform template
run: terraform validate
- name: Get short commit SHA to use as template version name
id: name
run: echo "version_name=$(git rev-parse --short HEAD)" >> "$GITHUB_OUTPUT"
- name: Get latest commit title to use as template version description
id: message
run:
echo "pr_title=$(git log --format=%s -n 1 ${{ github.sha }})" >>
$GITHUB_OUTPUT
- name: Push template to Coder
run: |
coder templates push $TEMPLATE_NAME --activate=false --name ${{ steps.name.outputs.version_name }} --message "${{ steps.message.outputs.pr_title }}" --yes
- name: Create a test workspace and run some example commands
run: |
coder create -t $TEMPLATE_NAME --template-version ${{ steps.name.outputs.version_name }} test-${{ steps.name.outputs.version_name }} --yes
# run some example commands
coder ssh test-${{ steps.name.outputs.version_name }} -- make build
- name: Delete the test workspace
if: always()
run: coder delete test-${{ steps.name.outputs.version_name }} --yes
- name: Promote template version
if: success()
run: |
coder template version promote --template=$TEMPLATE_NAME --template-version=${{ steps.name.outputs.version_name }} --yes