system connection remove: use Args function to validate#23326
system connection remove: use Args function to validate#23326openshift-merge-bot[bot] merged 1 commit intocontainers:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Will this PR resolve the following flake? (one-off just now, on my laptop, with #23325 but without #23326. And, sorry, I did not save logs. Will apply #23326 and keep trying, with logs). |
|
Test failure is real; new code needs to account for |
Oh how did I miss that, of course there was a reason for it in the first place. |
|
Ugh. Sorry, fixed. Anyhow, no, that failure is pretty persistent, I'm trying to reproduce it and will file an issue |
Using the ExactArgs(1) function is better because we have less duplication of the error text and the ValidArgsFunction uses that to suggest shell completion. The command before this commit would suggest connection names even if there was already one arg on the cli set. However because there is the --all option we still must exclude that first. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
3d18d23 to
85f4f89
Compare
|
Nah that would still be #23282, my PR should definitely fix the no such pod error, just because I added more context doesn't mean the cause is different. Something must be weird about how we lock things there |
|
@containers/podman-maintainers PTAL This is needed for the parallel sys test work. |
|
LGTM and I'm not seeing the otherwise-almost-constant completion test failure. Thank you! /lgtm |
Using the ExactArgs(1) function is better because we have less duplication of the error text and the ValidArgsFunction uses that to suggest shell completion. The command before this commit would suggest connection names even if there was already one arg on the cli set.
Does this PR introduce a user-facing change?