Add experimental functionality for labelling PRs by their size - #3218
Add experimental functionality for labelling PRs by their size#3218henrymercer merged 6 commits into
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
Pull Request Overview
This PR adds experimental functionality for automatically labeling pull requests by their size to help assess review difficulty. The implementation uses the sizeup-action to analyze PR changes and apply size labels (XS, S, M, L, XL, XXL) based on lines of code changed.
- Introduces a GitHub Actions workflow that triggers on PR events to automatically label PRs
- Configures six size categories with different thresholds and color-coded labels
- Excludes generated files and focuses scoring on meaningful code changes
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| .github/workflows/label-pr-size.yml | GitHub Actions workflow that runs the sizeup action on PR events |
| .github/sizeup.yml | Configuration file defining size categories, scoring formula, and file exclusions |
Sorry, something went wrong.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
| on: | ||
| pull_request: | ||
| types: | ||
| - opened | ||
| - synchronize | ||
| - reopened | ||
| - edited | ||
| - ready_for_review |
There was a problem hiding this comment.
We have other workflows with these (or mostly these) triggers. Could we add this as a job to e.g. pr-checks.yml?
Sorry, something went wrong.
There was a problem hiding this comment.
The PR checks also trigger on pull_request and workflow_dispatch. We could filter out those triggers with an if but I'm not sure of the benefit.
Sorry, something went wrong.
Co-authored-by: Michael B. Gale <mbg@github.com>
Label PRs by their size to give a quick assessment of how difficult they might be to review.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Merge / deployment checklist