Test-infra: Support repo-scoped labels

[nikhita]

Would be nice to scope labels per repo in labels_sync. See https://github.com/kubernetes/test-infra/pull/8335#issuecomment-396681981 for more context.

/cc @fejta @cblecker

[nikhita]

/kind feature

[nikhita]

/sig contributor-experience

[justaugustus]

/sig testing
/sig contributor-experience
/help

[fejta]

This can/should follow the pattern in https://github.com/kubernetes/test-infra/tree/master/prow/cmd/branchprotector (or prow/cmd/peribolos)

[nikhita]

one more reason why we should have this: k/k has area/* labels but they are not present in https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md. These labels are also, by virtue, highly specific to k/k.

(There are many more such labels in k/k. area/* is just one example.)

[matthyx]

In PR #8335 @stevekuznetsov and @cjwagner write about a label framework... is it usable now for this issue?

[stevekuznetsov]

Not yet -- the PR for the framework is in #8131

[matthyx]

Alright, so it has little to do with labelsync... I will see if I can implement something with the same pattern matching as branchprotector, as @fejta suggests.

[matthyx]

/remove-help
/assign

[matthyx]

Can we agree on this new format for labels.yaml ?

[stevekuznetsov]

Is there a design for the new format somewhere to review?

[matthyx]

Sorry, I did the new format inside the PR... I realize now that is was misleading. Here is an example:

# Keys for each item: color, description, name, target, deleteAfter, previously
#   deleteAfter: 2006-01-02T15:04:05Z (rfc3339)
#   previously: list of previous labels (color name deleteAfter, previously)
#   target: one of issues, prs, or both (also TBD)
#   addedBy: human? prow plugin? other?
---
labels:
  # Standard labels set (common for all kubernetes repos)
  common:
    - color: 0ffa16
      description: Indicates a PR has been approved by an approver from all required OWNERS files.
      name: approved
      target: prs
      prowPlugin: approve
      addedBy: approvers
    - color: fef2c0
      description: Indicates a cherrypick PR into a release branch has been approved by the release branch manager. # Consumed by the kubernetes/kubernetes cherrypick-queue.
      name: cherrypick-approved
      target: prs
      addedBy: humans
  # org specific labels
  orgs:
    # kubernetes org repos
    kubernetes:
      # kubernetes/kubernetes labels
      repos:
        kubernetes:
          - color: 0052cc
            description: Indicates an issue on admin area.
            name: area/admin
            target: issues
            addedBy: humans
          - color: 0052cc
            description: Indicates an issue on api area.
            name: area/api
            target: issues
            addedBy: humans

Basically existing labels would move under common and then a full orgs/myorg/repos/myrepo would contain labels specific to myorg/myrepo.

[stevekuznetsov]

Can we use

orgs:
  "*":

Instead of common?

[matthyx]

Very good idea, I like it!

[matthyx]

Actually I did it a bit differently, it's more compact that way. I let you check the PR.

[spiffxp]

/cc
looking forward to the PR

I had a bunch of conceptual hangups that kept me from moving forward on repo-scoped stuff, but it's the next logical step. Mainly centered around how we would DRY this up so that label docs are served on the fly per-org / per-repo, in much the same way we do today with prow commands and plugins.

[matthyx]

@nikhita you can safely start adding kubernetes/kubernetes specific labels to labels.yaml

[nikhita]

@nikhita you can safely start adding kubernetes/kubernetes specific labels to labels.yaml

This is so cool! Thanks, @matthyx! :tada:

Will do, added to my todo list.