Skip to content
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

Merged
merged 1 commit into from
Oct 31, 2024

Conversation

CelineTrammi
Copy link
Collaborator

@CelineTrammi CelineTrammi commented Oct 31, 2024

Description

Related Issue(s)

Verification

  • Your code builds clean without any errors or warnings
  • Manual testing done (required)
  • Relevant automated test added (if you find this hard, leave it and we'll help out)
  • All tests run green

Documentation

  • User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

Summary by CodeRabbit

  • New Features
    • Introduced a GitHub Actions workflow to enforce labeling on pull requests, ensuring they meet specific criteria before being processed.

Copy link

coderabbitai bot commented Oct 31, 2024

📝 Walkthrough

Walkthrough

A new GitHub Actions workflow file named check-label-for-pr.yml has been added to the repository. This workflow activates on various pull request events, including opening, reopening, and labeling. It features a job that runs on Ubuntu and uses the mheap/github-action-required-labels@v5 action to enforce the presence of at least one label from a specified list, which includes labels like kind/breaking-change, kind/feature, and kind/bug.

Changes

File Path Change Summary
.github/workflows/check-label-for-pr.yml New workflow added to check for required labels on pull requests.

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@CelineTrammi CelineTrammi added kind/chore Routine task or minor maintenance work that doesn't introduce new features or functionality ignore-for-release pull request wont be included in release notes labels Oct 31, 2024
Copy link

@coderabbitai coderabbitai bot left a 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 descriptive

The 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

📥 Commits

Reviewing files that changed from the base of the PR and between 4453ec4 and 9fdead8.

📒 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

  1. Some labels appear to have overlapping purposes:
    • kind/feature vs kind/feature-request
    • kind/feature vs kind/enhancement
  2. 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:

  1. Used to automatically sync labels across repositories
  2. Referenced in documentation
  3. Used to generate label documentation

Would you like me to provide a template for the labels documentation?

.github/workflows/check-label-for-pr.yml Show resolved Hide resolved
.github/workflows/check-label-for-pr.yml Show resolved Hide resolved
Copy link

@coderabbitai coderabbitai bot left a 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:

  1. Add a label validation workflow to ensure label descriptions are standardized
  2. Implement a PR template that documents the required labels
  3. 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

📥 Commits

Reviewing files that changed from the base of the PR and between 4453ec4 and 9fdead8.

📒 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.

  1. Consider consolidating similar labels:
    • kind/feature and kind/feature-request seem to overlap
    • kind/enhancement might overlap with kind/feature
  2. 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 template
  • kind/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

.github/workflows/check-label-for-pr.yml Show resolved Hide resolved
.github/workflows/check-label-for-pr.yml Show resolved Hide resolved
@CelineTrammi CelineTrammi merged commit 57eef19 into main Oct 31, 2024
8 of 9 checks passed
@CelineTrammi CelineTrammi deleted the feat/label-check-for-prs branch October 31, 2024 14:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ignore-for-release pull request wont be included in release notes kind/chore Routine task or minor maintenance work that doesn't introduce new features or functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants