Before you make a new release it may be prudent to delete any previously posted comments (made by the bot) when posting new comments to the same thread.

Sorry, I don't get your point, can you explain more?
I'm not an English native speaker, could you help to review and modify if need?
Thank you.

Imagine a PR is opened and the source file(s) invoke a bot comment from this action. Any successive commits to the same PR will only add more bot comments to that PR not replace or remove any outdated bot comments.

There is a way to update a comment via the REST API.

I think the repo's description should be updated also. This is to make it stick out less like a duplicate and more like an improved fork
image
vs the older
image

This can be only done by you in the repo's sidebar's settings
image

👍 I will update in one hour when I back from lunch/dinner.

Or change the repo's description to "GitHub Action for Linting C/C++ code as part of your workflows!". your thoughts?

I think after this release, the name of this GitHub app should be changed to "C/C++ Lint Action"

Best to use the words (in the description)

• "improved" (or something similar - maybe "evolved")
• "push" (non-negotiable)
• "pull_request" (maybe implied but could be informative)
• you're on the right track with "workflows"

I think the name (if changed) would need to be done prior to release. See the GH docs about action.yml metadata. IMHO, I like the idea of renaming the action also (I also like your suggested idea).

"IMPROVED C/C++ Lint Action: Automatically checks pull/pull_request changes with clang-tidy, clang-format, and posts the comment with result.", like this?

How do you like this?

Improved C/C++ Lint Action: Automatically checks push & pull request changes with clang-tidy & clang-format, then posts a comment with faulty results

Imagine a PR is opened and the source file(s) invoke a bot comment from this action. Any successive commits to the same PR >will only add more bot comments to that PR not replace or remove any outdated bot comments.

There is a way to update a comment via the REST API.

Yes, this is a problem. but if only has opened type event of pull_request, new commits include new source file(s) changes will not have bot comments. does REST API can deal with this

That only avoids duplicate triggered runs for 1 commit. I want to avoid a scenario like what I see in one of my testing PRs Notice the multiple comments made.

Maybe we can create another ticket to track avoid duplicate comments issue rather than limit pull_request type to opened

For this version, I guess it's ready to release. assign to you for review.

It seems there is no way to see how many users are using this app. I guess very little.
This version is much better than before, and we should let them see it as soon as possible.

Technically the marketplace's page for this action is up-to-date with the repo's master branch (despite if a release has happened or not).

You're right. the release looks only affect the app's name and description.