Cherrypick behaviour is different depending on PR author and whether you use a label or a comment

[craigbox]

We have had intermittent problems in Istio where setting a cherry-pick label on an issue would not cause the cherrypicker to run, but the same person leaving a comment would.

PR that shows failure: https://github.com/istio/istio.io/pull/16501 (first comment ignored, setting label ignored, second comment worked) PR that shows success: https://github.com/istio/istio.io/pull/16505

We have today narrowed it down to this set of circumstances:

• Only org members are allowed to trigger Prow actions
• Prow treats a cherrypick label as a comment from the PR author, not from the person who set the label
• The people who set the cherrypick label are almost always org members

Thus, one of the following things might be an improvement:

• The cherrypick label is treated as a comment from the person who set the label, not the PR author
• (if the above is somehow insecure) A comment is left saying that the user doesn't have access to interact with Prow and that no action will be taken, so they can know to make a comment (or add/remove the label?)

[smg247]

It does indeed treat the label as having been added by the added by the PR author, no matter who added it: https://github.com/kubernetes-sigs/prow/blob/754d732be32a2625c446b2cc92767d64a5802e2a/cmd/external-plugins/cherrypicker/server.go#L369-L385. This appears to be a result of the plugin only operating once a PR is merged, and the GH api not storing any information as to who added the label. This would be difficult to solve without re-architecting the plugin to use the label event when it comes in, and then storing the user who added the label somewhere for later reference.

It does seem like it would be somewhat trivial to leave a comment in the instance that a label was added that will be ignored due to the PR author not being an org member though.

[smg247]

By the way, you can configure the plugin to allow anyone to request a cherrypick: https://github.com/kubernetes-sigs/prow/blob/db89760fea406dd2813e331c3d52b53b5bcbd140/cmd/external-plugins/cherrypicker/main.go#L73

[craigbox]

Thanks @smg247; we did see that but we probably want to keep instructions to the bot restricted to org members. (The bar to becoming one is low.)

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 issue is closed

You can:

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

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 issue is closed

You can:

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

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

/lifecycle rotten

[craigbox]

/remove-lifecycle rotten /lifecycle staleproof