feat: use commit-check-action to check PR title#90
Conversation
Replace the committed-based PR title check with our own commit-check-action to eat our own dogfood. - Remove Rust toolchain installation (rustup, cargo-binstall, committed) - Add commit-check.toml config mirroring the existing committed.toml rules - Simplify to a single checkout (action auto-discovers config in .github/) - Keep cspell spell check as a separate step
|
This PR is not ready and still needs to think about how to make it work as expected. I will come back when I have time. |
We could have also just used My only main concern is adhering to conventional commits standards. This is because generating a changelog or release notes (via So, if [commit]
# https://www.conventionalcommits.org
conventional_commits = truemeans it enforces |
Resolve merge conflicts in pre-commit.yml: - Accept PR's approach: single checkout + commit-check-action instead of dual checkout + rustup/committed - Update actions/checkout to v7.0.0 (from main) - Remove rustup setup and committed installation steps (per PR intent) - Remove dual-repo cspell config fallback (per PR intent)
Sure. commit-check follows the https://www.conventionalcommits.org, so the above cases are fully covered. |
When a consuming repo doesn't have its own cspell.config.yml, download the org-level config from the .github repo as a fallback. Uses curl to fetch the file from the raw GitHub URL.
Instead of hardcoding 'main', use gh api to get the default branch of the action repository, falling back to 'main' on failure.
The spell check change is out of scope for this PR (which focuses on replacing committed with commit-check-action). Reverting back to the original approach from the PR author.
- Checkout .github repo to root (no path) so commit-check-action discovers .github/commit-check.toml automatically - Keep checkout of calling repo in project-repo/ for cspell - Remove second .github checkout to org-repo/ (replaced by root checkout) - Remove rustup/committed steps, add commit-check-action - Spell check if-else fallback preserved unchanged from main (path changes from org-repo/ to root since .github is now at root)
Co-authored-by: Xianpeng Shen <xianpeng.shen@gmail.com>
WalkthroughThis PR adds a ChangesPR title validation migration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. Comment |
SPELL_CONFIG -> CSPELL_CONFIG to match the variable referenced in the npx cspell-cli command
- Remove path from .github checkout so .github/commit-check.toml lands at workspace root for auto-discovery by the action - cspell fallback path adjusts accordingly: root instead of org-repo/ - Spell check if-else logic preserved unchanged from main
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/commit-check.toml:
- Around line 1-21: The commit subject length setting in the commit-check config
is now capped, which changes the previous unlimited behavior. Update the commit
validation config in the [commit] section by adjusting subject_max_length in
commit-check.toml so it preserves the intended unlimited length (use 0 or remove
the cap), and keep the conventional_commits-related settings consistent with the
existing validation rules.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0fd7c93c-25fc-4933-b2c3-939ed39a1d74
📒 Files selected for processing (2)
.github/commit-check.toml.github/workflows/pre-commit.yml
| [commit] | ||
| conventional_commits = true | ||
| subject_capitalized = false | ||
| subject_imperative = false | ||
| subject_max_length = 200 | ||
| subject_min_length = 1 | ||
| allow_commit_types = [ | ||
| "fix", | ||
| "feat", | ||
| "build", | ||
| "chore", | ||
| "docs", | ||
| "style", | ||
| "refactor", | ||
| "remove", | ||
| "deprecate", | ||
| "security", | ||
| "add", | ||
| "perf", | ||
| "test", | ||
| ] |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Search for commit-check-action documentation or config schema references in the repo.
# Also check if the old committed.toml is still present (PR says it remains for now).
# Check for any documentation about commit-check config
rg -i "commit-check" --type yaml --type markdown -n -C3 || true
# Verify the old committed.toml still exists
fd "committed.toml" .github/
# Check if any other files reference commit-check.toml or its keys
rg -i "allow_commit_types\|conventional_commits\|subject_max_length\|subject_min_length\|subject_imperative" -n -C2 || trueRepository: cpp-linter/.github
Length of output: 432
🌐 Web query:
What is the config schema for commit-check-action v2.9.0 commit-check.toml? What are the valid config keys under the [commit] section?
💡 Result:
The commit-check-action v2.9.0 uses a TOML-based configuration file (typically named commit-check.toml or cchk.toml) to define validation rules [1][2]. The configuration is managed by the underlying commit-check engine [3][4]. Valid configuration keys under the [commit] section include: conventional_commits (bool): Enables or disables validation against the Conventional Commits specification [5][6]. message_pattern (str, optional): A custom regex pattern to validate commit messages, which overrides the conventional_commits rule [6]. subject_capitalized (bool): Enforces that the commit subject starts with a capital letter [5][6]. subject_imperative (bool): Enforces that the commit subject uses the imperative mood [5][6]. subject_max_length (int, optional): Sets the maximum allowed length for the commit subject [5][6]. subject_min_length (int, optional): Sets the minimum required length for the commit subject [5][6]. allow_commit_types (list[str]): A list of allowed commit types (e.g., feat, fix, chore) [5][6]. allow_merge_commits (bool): Whether merge commits are permitted [5][6]. allow_revert_commits (bool): Whether revert commits are permitted [5][6]. allow_empty_commits (bool): Whether empty commits are permitted [5][6]. allow_fixup_commits (bool): Whether fixup! commits are permitted [5][6]. allow_wip_commits (bool): Whether work-in-progress (e.g., WIP:) commits are permitted [5][6]. require_body (bool): Whether a body is required in the commit message [5][6]. require_signed_off_by (bool): Whether a "Signed-off-by" footer is required [5][6]. required_signoff_name (str, optional): A specific name required in the sign-off footer [6]. required_signoff_email (str, optional): A specific email required in the sign-off footer [6]. ignore_authors (list[str]): A list of author or co-author names to bypass commit checks (e.g., bots like dependabot[bot]) [5][7][6]. ai_attribution (str): Configures how AI-generated commit trailers are handled (e.g., ignore or forbid) [6]. Additionally, the configuration supports an inherit_from key at the root level to allow sharing and extending base configurations from other files, URLs, or GitHub repositories [1][2]. Users can also configure branch-specific rules under a separate [branch] section [5][6]. For IDE support, the schema is published on SchemaStore, allowing for automated validation and autocompletion in compatible editors [1].
Citations:
- 1: https://pypi.org/project/commit-check/2.9.0/
- 2: https://commit-check.github.io/commit-check/
- 3: https://github.com/marketplace/actions/commit-check-action
- 4: https://commit-check.github.io/commit-check/migration.html
- 5: https://github.com/commit-check/commit-check-action/blob/main/commit-check.toml
- 6: https://commit-check.github.io/commit-check/configuration.html
- 7: https://github.com/commit-check/commit-check/blob/main/docs/configuration.rst
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== tracked commit-check files ==\n'
git ls-files '.github/*commit*' '.github/*cchk*' '.github/*toml' | sort
printf '\n== commit-check.toml ==\n'
if [ -f .github/commit-check.toml ]; then
cat -n .github/commit-check.toml
fi
printf '\n== committed.toml ==\n'
if [ -f .github/committed.toml ]; then
cat -n .github/committed.toml
fi
printf '\n== references ==\n'
rg -n "commit-check|committed\.toml|allow_commit_types|subject_max_length|subject_length|conventional_commits|subject_min_length|subject_imperative" .github -S || trueRepository: cpp-linter/.github
Length of output: 2006
Keep the subject length unlimited if that’s the intent
subject_max_length = 200 changes the previous unlimited subject_length = 0 behavior and will start rejecting longer subjects; use 0 or omit the cap if that restriction isn’t intended.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/commit-check.toml around lines 1 - 21, The commit subject length
setting in the commit-check config is now capped, which changes the previous
unlimited behavior. Update the commit validation config in the [commit] section
by adjusting subject_max_length in commit-check.toml so it preserves the
intended unlimited length (use 0 or remove the cap), and keep the
conventional_commits-related settings consistent with the existing validation
rules.
|
✌️ hopefully it will work |
|
Well, it works! I noticed commit-check does not seem to check that the first word of the conventional commit title is an imperative verb. Committed did check for this, but there was some edge cases... Certain English words can be a noun or a verb (eg "lock", "default"). Committed often flagged titles that start with "default" as not starting with an imperative verb. I think this is fine for our case. Not enforcing strict rules of English allows for more flexibility. |
|
Nice! commit check also supports checking imperative verbs. it can enable from .github/.github/commit-check.toml Line 4 in fac89f0 |
2 participants
I've been maintaining commit-check for about 4 years now. It's mature enough to use the commit-check-action in their CI.
This PR eats my own dog food :)
What changed
Before: The check-pr-title job in pre-commit.yml installed a full Rust toolchain (rustup, cargo-binstall, committed) just to validate one PR title.
After: Uses commit-check-action with
pr-title: true. The action discovers.github/commit-check.tomlautomatically — no extra setup needed.Also added
commit-check.tomlto mirror the rules we had incommitted.toml.Diff
.github/)+27 -30netNot in this PR
.github/committed.tomlis kept for now (can clean up later)commit-check.tomlor useinherit_from— that's a follow-upSummary by CodeRabbit