-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Workflow to verify future PRs contain a label that is used for release notes #565
Conversation
📝 WalkthroughWalkthroughA new GitHub Actions workflow file named Changes
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
.github/workflows/check-label-for-pr.yml (1)
5-9
: Make job name more descriptiveThe job name 'label' is too generic. Consider using a more descriptive name that reflects its purpose.
jobs: - label: + verify-release-label: runs-on: ubuntu-latest permissions: pull-requests: write
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/check-label-for-pr.yml
(1 hunks)
🔇 Additional comments (1)
.github/workflows/check-label-for-pr.yml (1)
11-25
: Review and document label taxonomy
- Some labels appear to have overlapping purposes:
kind/feature
vskind/feature-request
kind/feature
vskind/enhancement
- Consider adding documentation that explains:
- The purpose and criteria for each label
- When to use one label over another
- How these labels map to release notes
Let's check if there's existing label documentation:
#!/bin/bash
# Search for label documentation in common locations
echo "Checking for label documentation..."
rg -l "kind/(feature|bug|breaking-change)" "docs/" "README.md" ".github/"
Consider creating a .github/labels.yml
file to maintain label definitions in a structured format, which can be:
- Used to automatically sync labels across repositories
- Referenced in documentation
- Used to generate label documentation
Would you like me to provide a template for the labels documentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
.github/workflows/check-label-for-pr.yml (1)
1-25
: Consider implementing additional label validation mechanisms.While this workflow ensures a label is present, consider these architectural improvements:
- Add a label validation workflow to ensure label descriptions are standardized
- Implement a PR template that documents the required labels
- Consider automating label application based on PR content analysis
Would you like assistance in implementing any of these suggestions?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/check-label-for-pr.yml
(1 hunks)
🔇 Additional comments (1)
.github/workflows/check-label-for-pr.yml (1)
11-25
: 🛠️ Refactor suggestion
Enhance label configuration and user feedback.
- Consider consolidating similar labels:
kind/feature
andkind/feature-request
seem to overlapkind/enhancement
might overlap withkind/feature
- Add a custom error message to guide users
- uses: mheap/github-action-required-labels@v5
with:
mode: minimum
count: 1
+ error_message: "Your PR must include exactly one 'kind/*' label for release notes. Please add an appropriate label from: breaking-change, feature, bug, enhancement, dependencies, etc."
labels: |
kind/breaking-change
kind/feature
- kind/feature-request
kind/bug
kind/other
kind/user-story
kind/dependencies
kind/enhancement
kind/incident
kind/chore
Let's verify if these labels are consistently used across the repository:
✅ Verification successful
Let me check the issue templates to understand how these labels are being used.
Keep all current labels but improve error message guidance
After analyzing the issue templates and release configuration, I need to revise my earlier suggestion. The labels currently defined in the PR check are all actively used:
kind/feature-request
is used in feature request templatekind/feature
is used for implemented features in changelog- All other labels map to specific issue templates or changelog categories
Suggested changes:
- uses: mheap/github-action-required-labels@v5
with:
mode: minimum
count: 1
+ error_message: "PR must include one 'kind/*' label. Choose:\n- kind/breaking-change: Breaking API changes\n- kind/feature: Implemented features\n- kind/feature-request: Feature proposals\n- kind/bug: Bug fixes\n- kind/enhancement: Minor improvements\n- kind/dependencies: Dependency updates\n- kind/chore: Maintenance tasks\n- kind/incident: Incident fixes\n- kind/user-story: User story implementation\n- kind/other: Other changes"
labels: |
kind/breaking-change
kind/feature
kind/feature-request
kind/bug
kind/other
kind/user-story
kind/dependencies
kind/enhancement
kind/incident
kind/chore
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if these labels are already in use and documented
# Check for label usage in existing PRs
gh pr list --limit 100 --json labels,number,title | jq -r '.[] | "PR #\(.number): \(.title)\nLabels: \(.labels[].name)\n"'
# Check if labels are documented in contributing guidelines
rg -l "kind/" .github/ docs/ CONTRIBUTING.md || echo "No label documentation found"
Length of output: 945
Script:
#!/bin/bash
# Check content of issue templates and release config for label usage
for file in .github/ISSUE_TEMPLATE/*.{yml,md} .github/release.yml; do
echo "=== $file ==="
cat "$file" 2>/dev/null || true
echo -e "\n"
done
Length of output: 11653
Description
Related Issue(s)
Verification
Documentation
Summary by CodeRabbit