HDDS-15378. Add component labels for PRs based on changed files

[chihsuan]

What changes were proposed in this pull request?

Problem. Component labels are not applied consistently, so reviewers cannot reliably filter PRs by area such as SCM, OM, datanode, Recon, or S3.

HDDS-10450 previously added actions/labeler using pull_request_target. HDDS-13777 removed it because the labeler-only green checkmark could be mistaken for completed CI.

Solution. Extend the existing scheduled labeling workflow without using pull_request or pull_request_target, so labeling does not produce a check on individual PRs.

• Add .github/labeler.yml, mapping changed paths to 13 existing labels: scm, om, datanode, recon, s3, client, ofs, EC, command-line, tools, documentation, UI, and CI. No new labels are created.
• Add a component-labeler job that lists all open PRs and passes their numbers to the SHA-pinned actions/labeler.
• Enable sync-labels: true. Labels in .github/labeler.yml are automation-owned and are added or removed according to the current changed files. Unlisted labels, such as zdu and needs review, are not modified.
• Use a sparse checkout of .github so the configuration is read locally rather than fetched through the API for every PR.
• Keep the existing zdu branch-labeling logic. base-branch matching does not work when actions/labeler is invoked through pr-number from a scheduled workflow because the event payload contains no PR branch information.
• Reduce the schedule from every 5 minutes to every 30 minutes. With approximately 125 open PRs and three API requests per PR, the previous cadence would exceed the GITHUB_TOKEN limit of 1,000 requests per hour. The tradeoff is that labels may take up to 30 minutes to appear.

Expected first-run impact. Simulating the rules against the current 125 open PRs would add approximately 146 labels and remove approximately five existing managed labels that do not match the changed paths.

One open question is the meaning of s3: some PRs use it as a topic label without modifying S3 Gateway paths. For example, #10006 is an S3 design doc, labeled s3 by topic, but it only changes hadoop-hdds/docs, so the sync would replace s3 with documentation there. A path-based rule cannot reproduce that usage. If s3 should remain manually managed, its rule can be removed from .github/labeler.yml.

Release/backport, patch-size, review-state, and Jira labels are left for separate changes.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15378

How was this patch tested?

• rat.sh passed; actionlint and zizmor reported no new findings.
• Tested end-to-end with six PRs on a fork:
  https://github.com/chihsuan/ozone/actions/runs/30018395798
• Covered single and multiple component paths, root Markdown files, UI and CI paths, a zdu PR, and multiple PR numbers in one invocation.
• Verified that:
  • labels are added after new component files are pushed;
  • managed labels are removed after a revert or when manually applied to a non-matching PR;
  • unmanaged labels such as zdu and needs review remain unchanged; and
  • the configuration is read from the sparse checkout.
• Simulated the rules against all current open PRs to measure the first-run impact.

Generated-by: Claude Code (Opus 4.8)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.