plugin/label: Improve error when adding/removing a restricted label

[stephenfin]

Currently, if you attempt to add a restricted label and allowed_teams is unset/empty, you get the following unhelpful message.

@username: Can not set label cherry-pick-approved: Must be member in one of these teams: []

Improve this so that we no longer suggest being a member of no team and instead suggest reaching out to one of the users in allowed_users instead:

@username: The label(s) `restricted-label` cannot be applied or removed, because you are not in one of the allowed teams and are not an allowed user. Consider assigning one of the following members: Mallory

We also improve the common path where allowed_teams is populated, aligning the error message with those of other errors paths:

@username: The label(s) `restricted-label` cannot be applied or removed, because you are not in one of the allowed teams and are not an allowed user. Must be a member of one of these teams: privileged-group

[!NOTE] I suspect dumping a list of users could get "chatty", so I've intentionally avoided formatting these as links (i.e. we emit user, not @user) ~and only print up to 3 users. In most cases, this code should not be triggered since projects will usually make use of allowed_teams.~ EDIT: I've now bumped this to 20, per feedback, which should allow us to dump all but the largest list of users.

[!NOTE] I'm still not entirely happy with this either. For example, see here. That error messages suggests only a member of openshift-staff-engineers can set the label, when in reality there are many users that can set it. Perhaps we should reword this as either-or ("you must be a member of these groups: xyz. Alternatively, consider assigning one of these members: abc"). Open to idea here.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: stephenfin Once this PR has been reviewed and has the lgtm label, please assign cjwagner for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• pkg/plugins/OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[netlify[bot]]

✅ Deploy Preview for k8s-prow ready!

Name	Link
🔨 Latest commit	c4d5b43f367cd8e515acb7ccd7afb8875260bb30
🔍 Latest deploy log	https://app.netlify.com/projects/k8s-prow/deploys/68d10f50232c6d0008cda562
😎 Deploy Preview	https://deploy-preview-469--k8s-prow.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[stephenfin]

/test pull-prow-integration

That...doesn't look related...

[stephenfin]

/retest-required

pull-prow-unit-test-race-detector-nonblocking is failing on pkg/interrupts/interrupts_test.go:183, which I'm not touching here.

pull-prow-integration failed on the same test, but again this doesn't look related

[smg247]

I see no reason why the message can't display the allowed teams and (a subset of) the allowed users as well. You can format a GH message so that it hides content by default to be expanded, maybe if the list is longer than 5 or so you can put an ellipsis, and hide the rest behind it. I am not sure that I would bother with returning random users. In situations where there are 20+ users, maybe just return the first 20... WDYT?

[stephenfin]

I see no reason why the message can't display the allowed teams and (a subset of) the allowed users as well. You can format a GH message so that it hides content by default to be expanded, maybe if the list is longer than 5 or so you can put an ellipsis, and hide the rest behind it. I am not sure that I would bother with returning random users. In situations where there are 20+ users, maybe just return the first 20... WDYT?

If you're happy, I'm happy. I'll bump the limit to 20 now.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[stephenfin]

/remove-lifecycle stale

[petr-muller]

/cc