Allow /approve to be misspelled as /approved

[danwinship]

Tim did this here a while back and then Clayton just did it twice here and here, and those are just ones I know about... (It doesn't seem to be possible to search PRs for the string "/approved"; github just ignores the slash.)

Anyway, a modest proposal.
(This intentionally does not change any of the documentation, though maybe it ought to be mentioned somewhere?)

[ardaguclu]

@danwinship this one is another one openshift/origin#26344

[alvaroaleman]

/hold
I like it, @cblecker @chaodaiG @stevekuznetsov WDYT?

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alvaroaleman, danwinship

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• prow/OWNERS [alvaroaleman]

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

[chaodaiG]

LGTM as well, left a nit

There are two different places this could be mentioned:

test-infra/prow/plugins/approve/approve.go

Line 132 in ede436e

pluginHelp := &pluginhelp.PluginHelp{

OR
https://github.com/kubernetes/test-infra/blob/master/prow/ANNOUNCEMENTS.md

[chaodaiG]

nit: wrongApproveCommand implies error to me, how about change it to misspelledApproveCommand?

alternatively, it might also take a slice like alternativeApproveCommands, or just combine with APPROVE to be underl approveCommands

[danwinship]

ok, I went with alternateApproveCommand. Doing a slice would have required a bunch more rewriting...

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.

[chaodaiG]

LGTM, please fix GOFMT error and I'll approve

[cblecker]

From a ContribEx standpoint, we have always shied away from aliases for core commands (especially undocumented ones). The reason for this, is it makes it difficult for new contributors to know and understand what the flow looks like and what they should be doing.

I know there's a desire to be smart here and try and "do the right thing" based on intent, but these have consistently shown to be problematic in the larger picture.

/hold

[karuppiah7890]

From a ContribEx standpoint, we have always shied away from aliases for core commands (especially undocumented ones). The reason for this, is it makes it difficult for new contributors to know and understand what the flow looks like and what they should be doing.

I know there's a desire to be smart here and try and "do the right thing" based on intent, but these have consistently shown to be problematic in the larger picture.

Do we document such issues around command aliases / decisions about moving away from aliases? With data (examples etc) and reasoning.

[karuppiah7890]

Maybe if aliases won't be supported, we can get more data around this later and if too many people use /approved, then we could maybe think about letting the bot comment and say something like did you mean /approve? but that might be too much to implement and unnecessary too. Just an idea based on the comment here - kubernetes/kubernetes#95768 (comment) and also based on experience in CLI commands which usually ask "Did you mean xyz?" when something unknown is typed

[k8s-triage-robot]

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

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

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR 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 and PRs.

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

You can:

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

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

/lifecycle rotten

[k8s-ci-robot]

@danwinship: PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

@danwinship: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-test-infra-prow-image-build-test	a874e96	link	true	/test pull-test-infra-prow-image-build-test
pull-test-infra-integration	a874e96	link	true	/test pull-test-infra-integration
pull-test-infra-unit-test	a874e96	link	true	/test pull-test-infra-unit-test

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-triage-robot]

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

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

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

Details

In response to this:

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

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

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.