Template Markdown Capabilities

Each SCM provider renders comment bodies, check-run output, and discussion posts through its own markdown engine. Writing templates that look great on GitHub but break on Bitbucket is easy. This page tells you exactly what each provider supports so you can write portable templates or tailor them per platform.

Feature matrix

Feature	GitHub	GitLab	Gitea	Bitbucket Cloud	Bitbucket Server	Azure DevOps	SourceHut
Bold	✅	✅	✅	✅	✅	✅	❌
Italic	✅	✅	✅	✅	✅	✅	❌
Strikethrough	✅	✅	✅	✅	✅	❌	❌
Inline code	✅	✅	✅	✅	✅	✅	❌
Code blocks	✅	✅	✅	✅	✅	✅	❌
Headings	✅	✅	✅	✅	✅	✅	❌
Ordered lists	✅	✅	✅	✅	✅	✅	❌
Unordered lists	✅	✅	✅	✅	✅	✅	❌
Task lists	✅	✅	✅	❌	❌	❌	❌
Tables	✅	✅	✅	⚠️	⚠️	✅	❌
Blockquotes	✅	✅	✅	✅	✅	✅	❌
Links	✅	✅	✅	✅	✅	✅	❌
Images	✅	✅	✅	❌	❌	✅	❌
`<details>/<summary>`	✅	✅	✅	❌	❌	❌	❌
Emoji	✅	✅	✅	✅	✅	✅	❌
Same-repo issue refs (`#123`)	✅	✅	✅	✅	✅	✅	❌
Cross-repo refs (`owner/repo#123`)	✅	✅	✅	✅	✅	❌	❌
PR/MR refs	`#123`	`!123`	`#123`	`#123`	`#123`	`#123`	❌
User mentions (`@user`)	✅	✅	✅	✅	✅	✅	❌
Auto-linked references	✅	✅	✅	✅	✅	✅	❌

⚠️ Bitbucket tables: Bitbucket renders GFM tables inconsistently across Cloud and Server versions. Bold lists are a safer choice for structured data.

SourceHut: Uses an email/patch-based workflow. No markdown rendering at all. The commit status API exists, but comment bodies are not applicable.

API field limits

Every provider enforces maximum lengths on different fields. The relay applies Truncate() automatically when needed, but you should design your templates to stay within these limits for the best readability.

Provider	Status Description	Status Context	Comment Body	Label Name
GitHub	140 chars	255 chars	65,000 chars	50 chars
GitLab	255 chars	N/A	1,000,000 chars	255 chars
Gitea	255 chars	255 chars	65,000 chars	50 chars
Bitbucket Cloud	255 chars	255 chars	65,000 chars	N/A
Bitbucket Server	255 chars	255 chars	65,000 chars	N/A
Azure DevOps	4,000 chars	N/A	65,000 chars	255 chars
SourceHut	N/A	N/A	N/A	N/A

What this means for your templates:

Status descriptions are the most constrained. GitHub allows only 140 characters. Keep status lines short and put details in the comment body instead.
Comment bodies are generous everywhere except SourceHut (which has no comments). GitLab allows 1MB, while others cap at 65K. The <details> collapse pattern works well for keeping comments scannable.
Status context strings (the check name shown in the commit status list) are limited to 255 characters on most providers. Azure DevOps and GitLab don’t use this field.
Label names range from 50 chars (GitHub, Gitea) to 255 (GitLab, Azure DevOps). Bitbucket doesn’t support labels at all.

Provider-specific notes

GitHub

Full GitHub Flavored Markdown. Use <details>/<summary> to collapse result tables, task lists for checklists, and tables for structured data. Auto-links #123 issues and PRs, @user mentions, and commit SHAs.

Best template candidates: github-pr-comment.tmpl, github-checkrun.tmpl.

GitLab

GitLab Flavored Markdown extends standard GFM. Merge request references use !123 instead of #123. Task lists (- [ ] / - [x]) work in notes. Tables and <details> are supported. Auto-links issues, MRs, and users.

Best template candidate: gitlab-note.tmpl.

Gitea

Nearly identical to GitHub’s GFM. Full support for tables, <details>, task lists, and cross-references. Works well with GitHub-style templates.

Best template candidates: gitea-pr-comment.tmpl, gitea-issue-comment.tmpl.

Bitbucket Cloud and Server

Basic formatting works (bold, lists, links, code blocks). Tables render inconsistently across versions. <details>/<summary> is not supported. Stick to bold lists for structured data instead of tables.

Best template candidate: bitbucket-comment.tmpl (uses bold lists, not tables).

Azure DevOps

GFM tables and code blocks render well. <details>/<summary> is not supported. The description field for commit statuses has a generous 4,000 character limit. Cross-repo references are not supported.

Best template candidate: azuredevops-comment.tmpl.

SourceHut

No markdown rendering. SourceHut uses email-based workflows with commit trailers. Templates are only meaningful for the commit status API (text description). Don’t attempt markdown formatting.

Writing portable templates

If you need a single template that works across providers, follow these guidelines:

Use bold lists instead of tables for structured data. Tables break on Bitbucket.
Avoid <details>/<summary> for Bitbucket and Azure DevOps. Use headings to separate sections instead.
Keep status descriptions under 140 characters to satisfy GitHub’s limit.
Use Truncate() for dynamic content like Description and result values. This prevents overflow on any provider.
Use IssueRef() and PRRef() domain helpers instead of hardcoded #123 syntax. These produce the correct syntax per provider (e.g., !123 for GitLab merge requests).
Test with the provider’s actual render preview before deploying templates to production.

The configmap-templates.yaml shipped with the Helm chart includes provider-specific templates that follow these rules. Start there and customize from a known-good baseline.