feat(cli): Add a flag status to delete cmd like list cmd of argo cli

[spencercjh]

Motivation

For #11555. @tooptoop4 wants to filter workflows more accurately and flexibly by status.

There are two supported flags associated with it:

• --field-selector: metadata.name=foo, metadata.namespace=bar
• --selector: workflows.argoproj.io/phase=Succeeded

It is not feasible to use the --field-selector to filter workflows by status because of the well-known reasons.

Using -l(--selector) would satisfy the need, but the labels are too long with a common prefix workflows.argoproj.io/. It is not convenient to use.

Luckily, argo list has a directly related flag --status to filter workflows by status like argo list --status Running. It is more convenient to use. I think it could be taken a step further by exempting users from using the shell combination like argo delete $(argo list --status Succeeded | awk '{print $1}')

Modifications

1. Add a flag --status to argo delete to filter workflows by status. It's an existing field of struct listFlags and can be used directly.

Verification

There was no test code for argo delete before. I run it locally and it works as expected.

[spencercjh]

#11557 does something similar, but I don't think flag pending makes sense, there shouldn't be such a tiny, fine-grained flag.

Also thanks for his/her PR. 🙏

[agilgur5]

It is not feasible to use the --field-selector to filter workflows by status because of the well-known reasons.

Using -l(--selector) would satisfy the need, but the labels are too long with a common prefix workflows.argoproj.io/. It is not convenient to use.

Agreed with this rationale. After you brought up the inadequacy of --field-selector in #11555 (comment), I thought label selectors could be a workaround as well, but I would agree that it is quite long to type out. In either case, I did mention selectors as a workaround.

Moreover, argo list already supports --status, so this is just exposing that existing flag to argo delete.

[agilgur5]

#11557 does something similar, but I don't think flag pending makes sense, there shouldn't be such a tiny, fine-grained flag.

I would normally agree with this, but given that there are already --running and --completed flags, it's not altogether new either. If those didn't exist already, I would definitely prefer to not increase the surface area.

In any case, I think that discussion should be had in that PR. This PR does not technically preclude that PR

[agilgur5]

one tiny comment I need to look at more closely, otherwise LGTM.
Thanks for your contribution!

[spencercjh]

Thank's for your review, your analysis is very detailed and careful. 👍 💯