Update version description in bug.yml

[Merikei]

Fixes #5228

Summary by CodeRabbit

• Documentation
  • Enhanced bug report form with clearer instructions for locating installed version information, directing users to the Config > Security & Updates section for both current and legacy versions.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Updated the bug report template's version field description to provide clear instructions for locating the WLED version across both newer and older versions. The new multiline YAML block guides users to Config > Security & Updates and references both "Installed version" (newer versions) and "Server message" (older versions) lines.

Changes

Cohort / File(s)	Summary
Bug Report Template Update .github/ISSUE_TEMPLATE/bug.yml	Updated version field description from single-line instruction to multiline YAML block with guidance for locating installed version via Config > Security & Updates, supporting both newer ("Installed version" line) and older ("Server message" line) WLED versions

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly describes the main change: updating the version description in the bug.yml file.
Linked Issues check	✅ Passed	The PR updates the version field description to provide followable instructions that reference both newer (Installed version) and older (Server message) UI elements, addressing the core issue #5228.
Out of Scope Changes check	✅ Passed	All changes are directly focused on fixing the bug report template's version instructions and are within the scope of issue #5228.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b821e20 and e4b0ee0.

📒 Files selected for processing (1)

• .github/ISSUE_TEMPLATE/bug.yml

🔇 Additional comments (1)

.github/ISSUE_TEMPLATE/bug.yml (1)

47-50: Clear improvement addressing issue #5228.

The updated instructions are much clearer and accommodate both newer versions (with "Installed version:") and older versions (with "Server message"). The YAML formatting is correct, and the use of HTML tags for visual emphasis is appropriate for GitHub issue templates. The "Installed version:" label has been verified as the correct label in the current WLED UI.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[softhack007]

I think the fix is correct, "server message" was changed to "Installed version" in 0.16 (main) with this commit: 7865985, and in 0.15.x with commit 2df536c.

As 0.16 will still need some time until officially released, I think it's a good idea to also have the info where to find the version and build nr in "older" releases.

[softhack007]

@coderabbitai what do the tags and do? Is adding HTML tags allowed for issue field descriptions?

[coderabbitai]

🧩 Analysis chain

🌐 Web query:

GitHub issue templates YAML HTML support description field

💡 Result:

Short answer: The top-level description in YAML issue forms/templates is plain text (not arbitrary HTML). Use the template/body fields (markdown or markdown-type form elements) for richer formatting. See GitHub's issue-forms docs and the example frontmatter showing description as a simple string and guidance to put formatted content in body fields. [1][2][3]

Sources

• GitHub: Configuring issue templates / Issue forms (example uses a plain string description). [1]
• GitHub: Manually creating an issue template — YAML front-matter (about/description keys). [2]
• Community gist / cheat-sheet noting description is a short string (≤200 chars) for YAML forms. [3]

---

🌐 Web query:

GitHub issue forms input field description HTML markdown support

💡 Result:

Short answer: Input-field descriptions in GitHub issue forms accept Markdown (e.g., links) but not arbitrary HTML. Use the form schema's markdown element or a textarea field (which supports the same Markdown as an issue body) for richer/longer formatted content. [1][2]

Sources:

• GitHub "Syntax for issue forms" (example uses a Markdown link in description). [1]
• Guide / docs explaining markdown and textarea behavior in issue forms. [2]

---

🌐 Web query:

GitHub issue forms HTML tags kbd samp rendering

💡 Result:

Yes — GitHub's markdown sanitizer allows and , and they render (typically) like inline code/monospace when content is shown in issues, PRs and comments. [1][2][3]

Sources:

• GitHub HTML whitelist (html-pipeline) showing kbd and samp allowed. [1]
• Stack Overflow summary referencing the whitelist. [2]
• Gist listing allowed GFM tags and noting kbd/samp render like code. [3]

---

@softhack007 Great questions!

What the tags do:

• <kbd> represents keyboard input and typically renders styled like a keyboard key (often with a subtle border/shadow effect)
• <samp> represents sample output or text from a computer program and renders in monospace font

Are they allowed?
Yes, HTML tags are supported in GitHub issue form descriptions. GitHub's markdown sanitizer includes <kbd> and <samp> in its whitelist of allowed HTML tags, so they will render properly in the issue template.

In this specific case:

• <kbd><samp>⚙️ Config</samp></kbd> will display "⚙️ Config" styled as both a keyboard key and monospace text
• <samp>Installed version: </samp> and <samp>Server message</samp> will display in monospace font to indicate these are literal text strings users should look for in the UI

These tags improve the clarity of the instructions by visually distinguishing UI elements and literal text from the surrounding description text.

[Merikei]

What they do together:

When the kbd element contains a samp element, it represents input based on system output, for example invoking a menu item.

— WHATWG (Web Hypertext Application Technology Working Group)

[coderabbitai]

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!