Consider switching to an existing supported commit message linter action #40

While this is a really nice project and it's clear a lot of care has gone into it (the speed of integrating the recent trailer handling that matches git interpret-trailers is a good example!) I can't help but ask whether it makes sense long-term to keep maintaining a custom checker. Several established, community-maintained commit message linters already exist and could do the same job. I don't know the history of the project, so there may be good reasons it was built from scratch. If so, please say so and feel free to close this. I think it would be good to document that in the README, but that's extra icing on the cake :-).

Reasoning

• Maintained by a wider community: Tools like commitlint and gitlint have many contributors and users. Edge cases like merge commits, reverts, fixup!/squash! commits, unusual trailers and Unicode have mostly been reported and fixed already. Maintenance, bug fixes and security updates would no longer fall only on this repo's maintainers.
• More features:
  • commitlint supports Conventional Commits out of the box (type(scope): subject), with shareable configs and rules for allowed types, scopes, case, and header, body and footer length.
  • gitlint covers everything this action checks today with built-in rules: title-max-length, body-max-line-length, body-is-missing, blank line between title and body (B6/body-first-line-empty). It also adds regex-based rules, rules to ignore some commits (e.g. merge or bot commits), and custom rules written in Python.
• Runs locally, not just in CI: Both tools work as a commit-msg git hook or a pre-commit hook. Developers find problems when they commit, not after pushing a PR and the same config file is used locally and in CI.
• Config in the repo: Rules live in a file (.gitlint, commitlint.config.js) instead of action inputs, so each project can adjust them without needing new inputs added here.
• Existing GitHub Actions: Ready-made actions already exist, e.g. wagoid/commitlint-github-action. gitlint is also easy to run in a single workflow step (pip install gitlint && gitlint --commits "$BASE..$HEAD").
• Familiar to contributors: External contributors to Qualcomm projects may already know these tools and their error messages.

Possible ways forward

1. Replace the logic in this action with a thin wrapper around gitlint (it's also Python, so it fits the current setup). Ship a default config that matches the current behaviour, so existing users don't see a change.
2. Deprecate this action and document the equivalent gitlint or commitlint setup in the README.
3. Keep the action as it is if there are requirements the existing tools can't meet. If so, it would be useful to write those down in the README so the reasoning is clear to future contributors.

Happy to help with a PR for whichever option (if any) makes sense. Thanks for the work on this!