chore: Create pr_lint #366
Conversation
WalkthroughThis pull request introduces a new GitHub Actions workflow named Changes
Possibly related PRs
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
.github/workflows/pr_lint (1)
24-41: Consider enhancing semantic validation configurationWhile the commit types are comprehensive, consider these improvements:
- Remove the non-standard 'break' type or document its purpose
- Add configuration for optional scopes and validation rules
Add these configurations to enhance validation:
with: types: | chore ci docs feat fix perf refactor revert test - break + # Allow optional scopes + requireScope: false + # Validate PR description format + validateSingleCommit: false + # Configure custom validation rules + subjectPattern: ^(?![A-Z]).+$ + subjectPatternError: PR title must start with lowercase
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/pr_lint(1 hunks)
🔇 Additional comments (2)
.github/workflows/pr_lint (2)
16-22: LGTM! Well-scoped job configuration
The job permissions follow the principle of least privilege, granting only the necessary access for PR and status operations.
1-44: Verify no conflicts with existing workflows
Let's ensure this new workflow doesn't conflict with any existing PR validation workflows.
✅ Verification successful
No conflicts found with the new PR workflow
The new workflow is safe to implement as it serves a distinct purpose and doesn't conflict with existing workflows:
- Existing PR workflows are focused on testing, linting, and specific example validations
- None of the existing workflows implement semantic PR title validation or release drafting
- The new workflow's triggers (
opened,reopened,edited,synchronize) are complementary to existing workflows
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for existing PR-related workflows
echo "Checking for existing PR workflows..."
fd -e yml -e yaml . .github/workflows -x grep -l "pull_request" {} \;
fd -e yml -e yaml . .github/workflows -x grep -l "semantic" {} \;
fd -e yml -e yaml . .github/workflows -x grep -l "release-drafter" {} \;
Length of output: 1083
Script:
#!/bin/bash
# Let's examine the content of these workflows to check for any conflicts
echo "Checking content of PR-related workflows..."
for file in $(fd -e yml -e yaml . .github/workflows); do
echo "=== $file ==="
# Look for specific PR validation or semantic versioning related configurations
grep -A 5 "pull_request" "$file" 2>/dev/null
grep -A 5 "semantic" "$file" 2>/dev/null
grep -A 5 "release-drafter" "$file" 2>/dev/null
done
Length of output: 13171
| - uses: release-drafter/release-drafter@v6 | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
Add release-drafter configuration file
The release-drafter action requires a configuration file to properly categorize changes and generate meaningful release notes.
Create .github/release-drafter.yml with this content:
name-template: 'v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
categories:
- title: '🚀 Features'
labels:
- 'feat'
- title: '🐛 Bug Fixes'
labels:
- 'fix'
- title: '🧰 Maintenance'
labels:
- 'chore'
- 'refactor'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
version-resolver:
major:
labels:
- 'major'
minor:
labels:
- 'minor'
patch:
labels:
- 'patch'
default: patch
template: |
## Changes
$CHANGES| on: | ||
| pull_request_target: | ||
| types: | ||
| - opened | ||
| - reopened | ||
| - edited | ||
| - synchronize |
There was a problem hiding this comment.
Security: Replace pull_request_target with pull_request
Using pull_request_target grants workflow access to repository secrets even for PRs from forks, which is unnecessary for PR title validation. Since this workflow only needs to check PR titles and manage labels, using pull_request would be more secure.
Apply this diff:
on:
- pull_request_target:
+ pull_request:
types:
- opened
- reopened
- edited
- synchronize📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: | |
| pull_request_target: | |
| types: | |
| - opened | |
| - reopened | |
| - edited | |
| - synchronize | |
| on: | |
| pull_request: | |
| types: | |
| - opened | |
| - reopened | |
| - edited | |
| - synchronize |
Added linter that checks PRs to make sure they conform to standards
Summary by CodeRabbit