[
https://issues.apache.org/jira/browse/HDDS-15378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18098503#comment-18098503
]
Chi-Hsuan Huang commented on HDDS-15378:
----------------------------------------
I used Claude Code to survey PR auto-labeling in other Apache projects (Hadoop,
Spark, Kafka, Iceberg, Beam, Airflow, Pulsar, Arrow, Superset, Flink, NiFi) and
would like to propose a scoped-down first step.
*Approach.* Most projects run actions/labeler on "{*}pull_request_target"{*},
like the Hadoop example linked above. However, Ozone already tried that
(HDDS-10450) and moved away in HDDS-13777, because the labeler-only run shows a
green check on fork PRs while the real CI is still pending approval. Spark
recently removed its labeler over "pull_request_target" concerns as well
(SPARK-55433).
Therefore, I suggest extending our existing scheduled label-pr workflow
instead: enumerate open PRs with `gh pr list` and pass them to actions/labeler
via its `pr-number` input, with declarative path rules in `.github/labeler.yml`
and `sync-labels` enabled. I validated this on a fork: multi-PR input, additive
labeling, and removal on revert all work. One limitation found: `base-branch`
matchers do not work in `pr-number` mode, so branch-based labels stay in the
existing `gh` job.
*Proposed scope, by the items listed in the description:*
1. *Component labels* (first PR): about a dozen path-based labels reusing
existing label names (scm, om, datanode, recon, s3, client, ofs, EC,
command-line, tools, documentation, CI). These would be automation-owned: added
and removed based on the changed files.
2. *Release/feature branch labels* (small follow-up PR): a generic rule in the
existing branch label job, e.g. label any PR whose base is not master with
`backport`, so future release branches need no workflow change.
3. {*}Patch size{*}: no surveyed project uses an s/m/l/xl ladder; the only
precedent is Kafka's single `small` label (under 100 changed lines) to help
committers find quick reviews. Suggest deferring, and adopting the single-label
form if there is interest.
4. {*}Jira specified / review required{*}: no surveyed project does these via
labels. Our CI already enforces the `HDDS-NNNN.` title format as a blocking
check, which is stronger than a label. Review-state labeling (like Kafka's
triage lifecycle or Flink's community-review bot) may be worth exploring, but
it is PR lifecycle management rather than path labeling, so I suggest tracking
it in a separate Jira if there is interest.
I have a working patch for item 1 and will open a PR shortly.
> Support Github labeler
> ----------------------
>
> Key: HDDS-15378
> URL: https://issues.apache.org/jira/browse/HDDS-15378
> Project: Apache Ozone
> Issue Type: New Feature
> Reporter: Ivan Andika
> Assignee: Chi-Hsuan Huang
> Priority: Major
>
> Similar to Hadoop Github action labeler
> (https://github.com/apache/hadoop/blob/trunk/.github/labeler.yml), let's
> support labeler to automatically label based on
> * Components touched (e.g. tools, client, SCM, OM, common, container, recon,
> UI, etc): This can allow to reviewers to be able to see when critical
> components is changed (e.g. StateMachine implementation)
> * Whether it is aimed for release branch (e.g. backport patch)
> * Size of the patch (s, m, xl, xlll)
> * Whether review is required, jira is specified, etc
> * Other labelling logic we can think of
> We can check other projects as well. Please note that we also want to be
> prudent in the labelling logic to prevent too many labels which will reduce
> the usefulness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
