chore: setup eslint-style repository labels and pr labeler

[Kuldeep2822k]

Setup ESLint-Style Repository Labels and Auto-Labeling

This PR introduces an automated, Infrastructure-as-Code (IaC) approach to managing repository labels and automatically tagging Pull Requests based on the files they modify.

🌟 Features

1. Declarative Label Management:
   • A core set of labels inspired by ESLint are defined in .github/labels.yml (e.g., core, documentation, build, dependencies, release: major).
   • A GitHub Actions workflow (sync-labels.yml) automatically synchronizes these labels to the repository whenever the file is updated.
2. Automatic PR Labeling:
   • Uses actions/labeler@v5 to inspect files modified in a Pull Request.
   • Maps directory paths securely via .github/labeler.yml to apply labels automatically. For example, changes in src/**/* get the core label, while changes in package.json get build and dependencies.

🏗 Architecture

graph TD
    subgraph Label Sync Process
      A[.github/labels.yml] -->|Push to main| B(Sync Labels Workflow)
      B -->|Creates/Updates| C[(GitHub Repo Labels)]
    end
    
    subgraph PR Labeling Process
      D[New/Updated PR] --> E{PR Labeler Workflow}
      E -->|Reads rules from| F[.github/labeler.yml]
      F -->|Matches paths| C
      E -->|Assigns Labels to| D
    end

Loading

🔒 Security

• Workflows adhere to the Principle of Least Privilege.
• pr-labeler.yml utilizes pull_request_target allowing it to safely assign labels on community forks.
• sync-labels.yml explicitly declares issues: write to manage labels regardless of default repo token restrictions.

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.

[coderabbitai]

Warning

Review limit reached

@Kuldeep2822k, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 15 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Free

Run ID: 9b885ac9-6af7-49f5-bfc9-31b4a4e2eca2

📥 Commits

Reviewing files that changed from the base of the PR and between 32b4b8e and 511f56e.

📒 Files selected for processing (4)

• .github/labeler.yml
• .github/labels.yml
• .github/workflows/pr-labeler.yml
• .github/workflows/sync-labels.yml

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Configure repo labels and automatic PR labeling via GitHub Actions

⚙️ Configuration changes ✨ Enhancement 🕐 20-40 Minutes

AI Description

• Add a declarative, ESLint-style label catalog for consistent repo taxonomy.
• Introduce a workflow to sync labels to the repository on labels.yml changes.
• Auto-apply PR labels based on modified paths using GitHub’s labeler action.

Diagram

graph TD
A[".github/labels.yml"] --> B(["Sync Labels workflow"]) --> C[("Repo labels")]
F["Pull Request"] --> E(["PR Labeler workflow"]) --> C
D[".github/labeler.yml"] --> E

subgraph Legend
  direction LR
  _file["Config file"] ~~~ _wf(["Workflow"]) ~~~ _db[("GitHub labels")]
end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Manual label management + reviewer-applied PR labels

• ➕ No workflow permissions surface area
• ➕ Avoids automation surprises (e.g., label deletions)
• ➖ Drifts over time; inconsistent label taxonomy
• ➖ Adds repetitive reviewer/maintainer work

2. Use only `actions/labeler` (skip repo label sync)

• ➕ Fewer moving parts (one workflow, one config)
• ➕ No need for issues: write permission
• ➖ Assumes labels already exist (bootstrapping and ongoing maintenance still manual)
• ➖ Renames/color/description consistency not enforced

3. Centralize label management via Probot/labels (or equivalent app)

• ➕ Mature label-sync behavior and admin tooling
• ➕ Potentially more flexible policy controls
• ➖ Additional external dependency/app installation
• ➖ May not align with GitHub Actions-only governance preferences

Recommendation: Keep the PR’s current approach (labels-as-code + PR auto-labeling). It cleanly separates concerns (label catalog vs. PR mapping), provides deterministic label state via sync, and enables consistent triage. The main caution is operational: skip-delete: false means labels not in .github/labels.yml will be removed—ensure that’s intended for this repo.

Files changed (4) +141 / -0

Other (4) +141 / -0

labeler.ymlDefine path-based PR label mapping rules +37/-0

Define path-based PR label mapping rules

• Adds 'actions/labeler' rules mapping changed-file globs to labels (e.g., 'src/**/*' → 'core', docs paths → 'documentation'). Includes build/dependency heuristics for 'package*.json' and CI/config files.

.github/labeler.yml

labels.ymlAdd ESLint-style repository label catalog +57/-0

Add ESLint-style repository label catalog

• Introduces a declarative list of repository labels with curated colors and descriptions, including release labels and operational status/priority labels.

.github/labels.yml

pr-labeler.ymlAdd PR auto-labeling workflow using 'actions/labeler' +18/-0

Add PR auto-labeling workflow using 'actions/labeler'

• Adds a 'pull_request_target' workflow to apply labels on PR open/sync/reopen. Uses least-privilege permissions ('contents: read', 'pull-requests: write') and enables label synchronization behavior via the action.

.github/workflows/pr-labeler.yml

sync-labels.ymlAdd workflow to sync repo labels from '.github/labels.yml' +29/-0

Add workflow to sync repo labels from '.github/labels.yml'

• Adds a workflow that runs on pushes to 'main' affecting '.github/labels.yml' (and via manual dispatch) to create/update/delete repo labels. Uses 'issues: write' to manage labels and 'crazy-max/ghaction-github-labeler@v5' for synchronization.

.github/workflows/sync-labels.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Label sync permission mismatch ✓ Resolved 🐞 Bug ☼ Reliability

Description

pr-labeler.yml enables sync-labels: true but does not grant issues: write, so the labeler
cannot create labels when needed and may error or fail to sync labels if a referenced label is
missing.

Code

.github/workflows/pr-labeler.yml[R16-18]

+        with:
+          repo-token: "${{ secrets.GITHUB_TOKEN }}"
+          sync-labels: true

Relevance

●●● Strong

Team has accepted explicit least-privilege workflow permissions; fixing missing issues: write
aligns with that reliability focus.

PR-#12

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow currently grants only contents: read and pull-requests: write while enabling
sync-labels. The upstream action documentation states that creating labels requires `issues:
write`, so the current permission set is insufficient if syncing/creation is attempted.

.github/workflows/pr-labeler.yml[11-18]
🌐 The action’s recommended permissions note that creating new labels requires issues: write, while applying existing labels requires pull-requests: write.
PR-#12

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR labeler enables `sync-labels: true` but only grants `pull-requests: write`. Per actions/labeler documentation, creating labels requires `issues: write`, so the workflow can fail if it needs to create missing labels.

## Issue Context
You already have a dedicated `sync-labels.yml` workflow to manage labels declaratively. The PR labeler can likely operate in “apply existing labels only” mode.

## Fix Focus Areas
- .github/workflows/pr-labeler.yml[11-18]

## Suggested changes
Choose one:
1. **Preferred (least privilege):** set `sync-labels: false` (or remove it) so the PR labeler only applies existing labels, relying on `sync-labels.yml` to ensure labels exist.
2. If you require the PR labeler to create labels, add `issues: write` to `permissions` (and accept the higher privilege).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unpinned actions on target ✓ Resolved 🐞 Bug ⛨ Security

Description

The PR labeler runs on pull_request_target (write-capable context) but references actions by
mutable tags (e.g., actions/labeler@v5), which weakens supply-chain hardening compared to the rest
of the repo’s SHA-pinned workflows and increases blast radius if a tag is ever compromised.

Code

.github/workflows/pr-labeler.yml[R14-16]

+    steps:
+      - uses: actions/labeler@v5
+        with:

Relevance

●●● Strong

Repo previously accepted SHA-pinning GitHub Actions to reduce supply-chain risk; this matches that
hardening standard.

PR-#12

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new PR-labeler workflow uses pull_request_target and runs actions/labeler@v5 by a mutable
tag. Existing workflows in this repo already pin core actions by SHA, showing an established
hardening standard that this PR regresses.

.github/workflows/pr-labeler.yml[3-18]
.github/workflows/sync-labels.yml[19-23]
.github/workflows/ci.yml[21-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New workflows reference third-party actions by major version tags (mutable), while existing repo workflows pin to full commit SHAs. This is especially sensitive for `pull_request_target` workflows because they run in the base-repo security context.

## Issue Context
`pull_request_target` is intentionally used to allow labeling PRs from forks, but that also means the action code itself should be pinned to avoid unexpected changes.

## Fix Focus Areas
- .github/workflows/pr-labeler.yml[14-18]
- .github/workflows/sync-labels.yml[19-23]

## Suggested changes
- Replace `actions/labeler@v5` with a full commit SHA (add a comment with the corresponding release tag).
- Replace `actions/checkout@v4` and `crazy-max/ghaction-github-labeler@v5` with SHAs as well, matching the pattern used in `.github/workflows/ci.yml`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Deletes automation labels ✓ Resolved 🐞 Bug ☼ Reliability

Description

The Sync Labels workflow is configured with skip-delete: false, so it will delete any repository
labels not declared in .github/labels.yml; that file currently omits labels referenced by
Dependabot (ci, actions), causing Dependabot labeling to fail or be skipped after a sync run.

Code

.github/workflows/sync-labels.yml[R25-27]

+          yaml-file: .github/labels.yml
+          skip-delete: false
+          dry-run: false

Relevance

●● Moderate

Risk seems plausible, but no close repo precedent on label-sync deletion behavior; change may be
debated by intent.

PR-#12

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

skip-delete: false instructs the label sync action to delete labels not declared in
.github/labels.yml. Dependabot is configured to apply ci and actions labels, but those labels
are not present in .github/labels.yml, so they are candidates for deletion and subsequent
Dependabot labeling failures/omissions.

.github/workflows/sync-labels.yml[23-27]
.github/dependabot.yml[33-41]
.github/labels.yml[1-57]
🌐 Dependabot assumes custom configured labels already exist and does not automatically create arbitrary labels; missing labels lead to errors/missing labeling.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`sync-labels.yml` runs the GitHub label sync with `skip-delete: false`, which deletes any labels not present in `.github/labels.yml`. The repo already has automation that expects certain labels (e.g., Dependabot configured labels), and those labels are not present in the new labels file.

## Issue Context
- Dependabot is configured to apply `ci` and `actions` labels to its PRs.
- Dependabot does not reliably create arbitrary configured labels; missing labels lead to errors or missing labeling.

## Fix Focus Areas
- .github/workflows/sync-labels.yml[23-27]
- .github/labels.yml[1-57]
- .github/dependabot.yml[33-41]

## Suggested changes
1. Add missing labels used by automation (at least `ci` and `actions`) into `.github/labels.yml`, OR update `.github/dependabot.yml` to only reference labels you manage here.
2. Consider setting `skip-delete: true` if the repository may have labels managed outside this file (to avoid unexpected deletions).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context

✅ Web pages:

  🌐 actions/labeler

  🌐 README.md

  🌐 HttpError: You do not have permission to create labels on this repository · Issue #870 · actions/labeler

  +12 more

Review mode: ⚖️ Balanced: This adds executable GitHub workflows with write permissions and PR-target automation; the security and configuration interactions warrant a complete single-pass review, but the change is not dense enough to require redundant passes.

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[greptile-apps]

Kuldeep2822k has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.