From b47eb3a8ac1ca1650315a4835d2b0217c16648ae Mon Sep 17 00:00:00 2001 From: Xianpeng Shen Date: Wed, 30 Sep 2026 10:39:57 +0300 Subject: [PATCH] docs: use the action's feature names on the home page The home page section "Results show up on the pull request" named the reports its own way ("Suggestions you can commit", "Notes in the diff", "One summary comment", "Fixes pushed for you"). Readers who then open cpp-linter-action find different names there, so the cards now use the action README's headings, each with the input that turns it on, in the same order as the organization profile banner (cpp-linter/.github#112): - Annotations `file-annotations` - Thread Comment `thread-comments` - Step Summary `step-summary`, new: the same report in the job summary, which also works on forks and in private repositories, where thread comments are turned off - Pull Request Review `tidy-review`, new card: clang-tidy diagnostics with suggested changes - Pull Request Review `format-review` - Auto-fix `auto-fix` Six cards fill the two-column grid in three rows. The section intro and the cpp-linter-action tool card ("thread comments or pull request reviews") use the same words. A new rule sets the input chip beside each title to 13px; it inherited 8.5px from the header. Checked with `mkdocs serve` at 1280px and 375px wide: three even rows on desktop, one column on phones, no horizontal scroll. The step summary and review wording follows `action.yml` (`step-summary` reuses the thread comment's content; thread comments are disabled on private repositories). --- docs/overrides/home.html | 74 ++++++++++++++++++++++++++++++--------- docs/stylesheets/home.css | 5 +++ 2 files changed, 62 insertions(+), 17 deletions(-) diff --git a/docs/overrides/home.html b/docs/overrides/home.html index 2b9c0c3..c1a17d2 100644 --- a/docs/overrides/home.html +++ b/docs/overrides/home.html @@ -147,7 +147,7 @@

{% set tools = [ { "title": "On every pull request", "name": "cpp-linter-action", "icon": "octicons/git-pull-request-24", - "text": "Annotates findings on the pull request. Pass GITHUB_TOKEN with pull-requests: write to add a summary comment or review suggestions. Linux, macOS and Windows runners.", + "text": "Annotates findings on the pull request. Pass GITHUB_TOKEN with pull-requests: write to add thread comments or pull request reviews. Linux, macOS and Windows runners.", "code": "uses: cpp-linter/cpp-linter-action@v2", "href": "https://cpp-linter.github.io/cpp-linter-action/", "cta": "Read the docs", }, @@ -238,20 +238,9 @@

{{ title }}

What reviewers see

Results show up on the pull request

-

Annotations are on by default. Review suggestions, a summary comment and auto-fix each take one input plus write access for the job.

+

Annotations are on by default and each of the others takes one input. Thread comments, pull request reviews and auto-fix also need write access for the job; the step summary shows on the workflow run.

-
- -

Suggestions you can commit

-

Set format-review or tidy-review and fixes for lines in the diff arrive as review suggestions. Needs pull-requests: write, so pull requests from forks get annotations only.

-
-

Notes in the diff

-

clang-tidy findings in the checked file are annotated on their line (GitHub shows up to 10 warnings per step), and clang-format adds one note per file. Annotations need no write access, so they also work on pull requests from forks.

+
+

Annotations

+ file-annotations +
+

On by default. clang-tidy findings in the checked file are annotated on their line (GitHub shows up to 10 warnings per step), and clang-format adds one note per file. Annotations need no write access, so they also work on pull requests from forks.

-

One summary comment

+
+

Thread Comment

+ thread-comments +

Set thread-comments: update and one comment lists the results, edited on each push while there are findings. It is posted by github-actions[bot] or your own App, and needs pull-requests: write, so it fails on pull requests from forks.

+
+ +
+

Step Summary

+ step-summary +
+

Set step-summary: true and the same report is added to the job summary of the workflow run. It needs no write access, so it also works on pull requests from forks and in private repositories, where thread comments are turned off.

+
+
+ +
+

Pull Request Review

+ tidy-review +
+

Set tidy-review: true and clang-tidy's fixes for lines in the diff are posted in a pull request review, as suggested changes under each diagnostic. Needs pull-requests: write, so pull requests from forks get annotations only.

+
+
+ +
+

Pull Request Review

+ format-review +
+

Set format-review: true and clang-format's fixes for lines in the diff are posted in a pull request review, as suggested changes you commit in one click. Same permission as tidy-review.

+