Add 'changed-files-labels-limit' and 'changed-files-labels-limit' configs to allow capping number of labels added

[bluca]

Description:
When a repository has many components, each with a changed-files label, a large refactor ends up with the labeler spamming the pull request with label changes. The end result is not very useful as it's not very readable, and due to how github automatically hides comments when label changes overflow the discussion tab, it means useful information is hidden and one has to manually click "Load more..." dozens of time every time the page is loaded.

Add a changed-files-limit top level config knob. If more than the configured limit of labels is set to be added, none are added. This only affects changed-files labels.

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[bluca]

Example of a PR where the labeling gets out of hands and spams the discussion page: systemd/systemd#40624

[Copilot]

Pull request overview

This PR adds a changed-files-limit configuration option to the labeler action to prevent label spam when large refactors touch many components. When the number of new changed-files labels exceeds the configured limit, all new changed-files labels are skipped, while branch-based labels and preexisting labels remain unaffected.

Changes:

• Added changed-files-limit top-level configuration option to cap the number of changed-files labels
• Implemented logic to track and differentiate between changed-files labels and branch-based labels
• Added comprehensive test coverage with 8 new test cases covering various limit scenarios

Reviewed changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/labeler.ts	Implements limit checking logic that tracks changed-files labels and removes them if the limit is exceeded
src/api/get-label-configs.ts	Adds parsing and validation for the new changed-files-limit config option and a helper function to identify changed-files labels
dist/index.js	Compiled JavaScript output reflecting the TypeScript changes
tests/main.test.ts	Adds 8 integration test cases covering various limit scenarios including edge cases with preexisting labels
tests/labeler.test.ts	Adds unit tests for the new parsing logic and configUsesChangedFiles helper function
tests/fixtures/*.yml	Four new YAML test fixtures with different limit configurations
README.md	Comprehensive documentation of the new feature with examples and usage guidance

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chiranjib-swain]

Hi 👋 thanks again for working on this — the option added in #923 to cap how many changed-files labels get applied is very useful for preventing label spam in large PRs.

One nuance though: it seems to address a slightly different problem than the original request in #486.

changed-files-limit currently limits how many labels are applied, while #486 was more about limiting labeling based on the overall size of the change (e.g., only apply file-based labels if fewer than N files changed).

Would you be open to extending this PR or adding a follow-up to support something like:

max-files-changed: N

If the total changed files exceed N, file-based labeling could be skipped entirely. This would align more closely with the original goal in #486 and also avoid unnecessary pattern scanning on very large PRs.

While reviewing the implementation and README, I also noted a few smaller suggestions:

1. Naming & Semantics

The name changed-files-limit can be somewhat ambiguous since it sounds like it limits the number of changed files, while it actually limits the number of labels generated by changed-files rules.

Suggestion

Consider renaming to something clearer like changed-files-labels-limit.

If renaming could break configs, we could support both names and treat changed-files-limit as a deprecated alias.

2. Stricter Configuration Parsing

The current parsing uses parseInt, which can silently accept invalid inputs.

Examples:

• "10abc" → interpreted as 10
• "3.2" → interpreted as 3

To make configuration validation stricter and safer:

• If the value is a string, require it to match /^\d+$/ before parsing.
• If the value is a number, validate with:

• Number.isInteger(value)
• Number.isFinite(value)

Potential tests:

• "10abc" → should throw an error
• "3.2" → should throw an error
• 3.2 (float) → should throw an error

3. Clarifying the Definition of a “Changed-Files Label”

One subtle behavior worth documenting is how the limit interacts with mixed rules.

Example:

changed-files-limit: 0

mixed-label:
 - any:
     - head-branch: "^test/"
     - changed-files:
         - any-glob-to-any-file: ["components/a/**"]

Even if the label matches via the branch rule, the presence of a `changed-files` rule causes it to be treated as a changed-files label and therefore subject to the limit.

It might help to document something like:

Any label definition that includes a `changed-files` rule is considered a changed-files label and is subject to changed-files-limit, regardless of which condition caused the label to match.

Adding a small dedicated test fixture could also help make this behavior explicit.

4. README Documentation

The new Configuration Options section is a great addition 👍. It might help to explicitly mention:

• The limit counts only new labels derived from changed-files rules (labels already present on the PR are ignored).
• Labels are skipped only when newChangedFilesLabels > limit. If newChangedFilesLabels === limit, they are still applied.
• If the limit is exceeded, all new changed-files labels are skipped for that run.
• Labels based on branch conditions (head-branch, base-branch) are not affected.

[bluca]

@chiranjib-swain thanks for the review, applied all suggestions and requests

[Copilot]

Pull request overview

Copilot reviewed 13 out of 14 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

Pull request overview

Copilot reviewed 13 out of 14 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[bluca]

Fixes the formatting issue (hopefully)

[bluca]

@chiranjib-swain anything else I can do here? Thanks