chihsuan opened a new pull request, #10851: URL: https://github.com/apache/ozone/pull/10851
## 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) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
