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.*
155 lines
4.9 KiB
Markdown
155 lines
4.9 KiB
Markdown
# Microsoft Teams Notifications
|
|
|
|
[Microsoft Teams](https://www.microsoft.com/en-us/microsoft-teams) is a widely
|
|
used collaboration platform, and with Coder's integration, you can enable
|
|
automated notifications directly within Teams using workflows and
|
|
[Adaptive Cards](https://adaptivecards.io/)
|
|
|
|
Administrators can configure Coder to send notifications via an incoming webhook
|
|
endpoint. These notifications appear as messages in Teams chats, either with the
|
|
Flow Bot or a specified user/service account.
|
|
|
|
## Requirements
|
|
|
|
Before setting up Microsoft Teams notifications, ensure that you have the
|
|
following:
|
|
|
|
- Administrator access to the Teams platform
|
|
- Coder platform >=v2.16.0
|
|
|
|
## Build Teams Workflow
|
|
|
|
The process of setting up a Teams workflow consists of three key steps:
|
|
|
|
1. Configure the Webhook Trigger.
|
|
|
|
Begin by configuring the trigger: **"When a Teams webhook request is
|
|
received"**.
|
|
|
|
Ensure the trigger access level is set to **"Anyone"**.
|
|
|
|
1. Setup the JSON Parsing Action.
|
|
|
|
Add the **"Parse JSON"** action, linking the content to the **"Body"** of the
|
|
received webhook request. Use the following schema to parse the notification
|
|
payload:
|
|
|
|
```json
|
|
{
|
|
"type": "object",
|
|
"properties": {
|
|
"_version": {
|
|
"type": "string"
|
|
},
|
|
"payload": {
|
|
"type": "object",
|
|
"properties": {
|
|
"_version": {
|
|
"type": "string"
|
|
},
|
|
"user_email": {
|
|
"type": "string"
|
|
},
|
|
"actions": {
|
|
"type": "array",
|
|
"items": {
|
|
"type": "object",
|
|
"properties": {
|
|
"label": {
|
|
"type": "string"
|
|
},
|
|
"url": {
|
|
"type": "string"
|
|
}
|
|
},
|
|
"required": ["label", "url"]
|
|
}
|
|
}
|
|
}
|
|
},
|
|
"title_markdown": {
|
|
"type": "string"
|
|
},
|
|
"body_markdown": {
|
|
"type": "string"
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
This action parses the notification's title, body, and the recipient's email
|
|
address.
|
|
|
|
1. Configure the Adaptive Card Action.
|
|
|
|
Finally, set up the **"Post Adaptive Card in a chat or channel"** action with
|
|
the following recommended settings:
|
|
|
|
**Post as**: Flow Bot
|
|
|
|
**Post in**: Chat with Flow Bot
|
|
|
|
**Recipient**: `user_email`
|
|
|
|
Use the following _Adaptive Card_ template:
|
|
|
|
```json
|
|
{
|
|
"$schema": "https://adaptivecards.io/schemas/adaptive-card.json",
|
|
"type": "AdaptiveCard",
|
|
"version": "1.0",
|
|
"body": [
|
|
{
|
|
"type": "Image",
|
|
"url": "https://coder.com/coder-logo-horizontal.png",
|
|
"height": "40px",
|
|
"altText": "Coder",
|
|
"horizontalAlignment": "center"
|
|
},
|
|
{
|
|
"type": "TextBlock",
|
|
"text": "**@{replace(body('Parse_JSON')?['title_markdown'], '"', '\"')}**"
|
|
},
|
|
{
|
|
"type": "TextBlock",
|
|
"text": "@{replace(body('Parse_JSON')?['body_markdown'], '"', '\"')}",
|
|
"wrap": true
|
|
},
|
|
{
|
|
"type": "ActionSet",
|
|
"actions": [@{replace(replace(join(body('Parse_JSON')?['payload']?['actions'], ','), '{', '{"type": "Action.OpenUrl",'), '"label"', '"title"')}]
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
_Notice_: The Coder `actions` format differs from the `ActionSet` schema, so
|
|
its properties need to be modified: include `Action.OpenUrl` type, rename
|
|
`label` to `title`. Unfortunately, there is no straightforward solution for
|
|
`for-each` pattern.
|
|
|
|
Feel free to customize the payload to modify the logo, notification title, or
|
|
body content to suit your needs.
|
|
|
|
## Enable Webhook Integration
|
|
|
|
To enable webhook integration in Coder, define the POST webhook endpoint created
|
|
by your Teams workflow:
|
|
|
|
```sh
|
|
export CODER_NOTIFICATIONS_WEBHOOK_ENDPOINT=https://prod-16.eastus.logic.azure.com:443/workflows/f8fbe3e8211e4b638...`
|
|
```
|
|
|
|
Finally, go to the **Notification Settings** in Coder and switch the notifier to
|
|
**Webhook**.
|
|
|
|
## Limitations
|
|
|
|
1. **Public Webhook Trigger**: The Teams webhook trigger must be open to the
|
|
public (**"Anyone"** can send the payload). It's recommended to keep the
|
|
endpoint secret and apply additional authorization layers to protect against
|
|
unauthorized access.
|
|
|
|
2. **Markdown Support in Adaptive Cards**: Note that Adaptive Cards support a
|
|
[limited set of Markdown tags](https://learn.microsoft.com/en-us/microsoftteams/platform/task-modules-and-cards/cards/cards-format?tabs=adaptive-md%2Cdesktop%2Cconnector-html).
|