.*: add delete-spam-issue prow plugin

[MadhavJivrajani]

Disclaimer: this commit is authored with the help of Claude Code.

This PR enables kubernetes/org#4994

There has been a plethora of spam issues created by bots across different repos today and cleaning them up is bottlenecked on the availability of GH admins. We've had amazing folks volunteer and report such spam in a timely manner (thank you @dims!) and they are also highly trusted members of the community.

Deleting issues requires admin privileges, and rather than giving volunteers these elevated privileges, this commit introduces a prow plugin that a subset of allowed contributors can use to delete an issue and not rely on GH admins since we've had an increasing number of "spam storms" wherein an account creates nonsense issues in a loop resulting in a lot of them just lurking around.

The current flow that I see taking place with this is as follows:

1. Contributor drops a message on the #github-management slack noting the user ID of the account that created the spam issue (in case admins need to block/report).
2. Contributor comments /delete-spam-issue

TODO: the above contributor workflow also needs to be documented in k/community.

Step (1) can be further automated since we already have alerts based on certain GH events to slack setup if needed.

Currently, the allowed contributors are as follows:

1. GitHub admins
2. @dims (kubernetes-admins group to help fight spam kubernetes/org#4994)

We can also use this to create a named contributor role for anyone that helps out in reporting spam.

/assign @kubernetes-sigs/owners
for initial review

[netlify]

✅ Deploy Preview for k8s-prow ready!

Name	Link
🔨 Latest commit	adac220
🔍 Latest deploy log	https://app.netlify.com/projects/k8s-prow/deploys/6a2ba5887dd4c70008621d57
😎 Deploy Preview	https://deploy-preview-752--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.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: MadhavJivrajani
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.

Details

Needs approval from an approver in each of these files:

• cmd/hook/OWNERS
• pkg/hook/OWNERS
• 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

[cblecker]

Nice work — this is a well-motivated plugin and the implementation is clean. A few thoughts:

Consider allowing root approvers from OWNERS to run this too. Right now the only way to authorize someone is to add them to allowed_users or allowed_teams in the central Prow config. You could add something like allow_top_level_approvers: true that lets top-level OWNERS file approvers for the repo also run the command. The pin-issue plugin already does this via owners.TopLevelApprovers() (see pkg/plugins/issue-management/pin-issue.go). That would make this more self-service for repos without needing a config change every time a new trusted person volunteers.

Consider optional safeguards to limit blast radius. Since issue deletion is permanent and irreversible, it might be worth adding optional config like max_issue_age_days and max_issue_comments — if an issue is older than N days or has more than M comments, the command would refuse to delete it. Spam issues are typically brand new with no legitimate interaction, so reasonable thresholds would catch accidental /delete-spam-issue on real issues without getting in the way of actual spam cleanup. These could default to zero (no limit) so the behavior is opt-in.

Minor test coverage note: The canUserDeleteIssue error path from TeamBySlugHasMember (when the API call itself fails) doesn't have test coverage. Given this is a destructive operation, it'd be good to have a test confirming the plugin returns an error and doesn't proceed with deletion when the permission check hits an API failure.

[MadhavJivrajani]

@cblecker

Consider allowing root approvers from OWNERS to run this too. Right now the only way to authorize someone is to add them to allowed_users or allowed_teams in the central Prow config. You could add something like allow_top_level_approvers: true that lets top-level OWNERS file approvers for the repo also run the command. The pin-issue plugin already does this via owners.TopLevelApprovers() (see pkg/plugins/issue-management/pin-issue.go). That would make this more self-service for repos without needing a config change every time a new trusted person volunteers.

I like this idea, I've pushed a commit that does this.

Consider optional safeguards to limit blast radius. Since issue deletion is permanent and irreversible, it might be worth adding optional config like max_issue_age_days and max_issue_comments — if an issue is older than N days or has more than M comments, the command would refuse to delete it. Spam issues are typically brand new with no legitimate interaction, so reasonable thresholds would catch accidental /delete-spam-issue on real issues without getting in the way of actual spam cleanup. These could default to zero (no limit) so the behavior is opt-in.

Hmm, that makes sense to me. However, spam issues can lurk around in repos that aren't super actively monitored and top level OWNERS can cleanup now as needed. Maybe we can do this as a followup if folks run into scenarios of accidental deletion (outcome is same if we don't have it right now vs have it and it be opt-in for a later point).

Minor test coverage note: The canUserDeleteIssue error path from TeamBySlugHasMember (when the API call itself fails) doesn't have test coverage. Given this is a destructive operation, it'd be good to have a test confirming the plugin returns an error and doesn't proceed with deletion when the permission check hits an API failure.

Done.

[petr-muller]

I wonder if this needs a separate new plugin - @Amulyam24's recent issue-management plugin seems like it could be a good home for the command. It currently does not have a config surface afaik but it should not be a problem to add it.