Loading
chore: forbid cobra.ExactArgs(0) in favor of cobra.NoArgs
Description
Commit 9523a73c (fix(commands): argument count limiters) converted cobra.ExactArgs(0) to cobra.NoArgs across 77 files, but added no enforcement. The pattern is already being reintroduced in new commands — !3781 adds two more instances, and Duo reviewed that MR without flagging them.
cobra.NoArgs names the unexpected argument in its error message; ExactArgs(0) only reports a count.
Why not golangci-lint
forbidigo matches call names, not argument values, so ^cobra\.ExactArgs$ would also ban legitimate ExactArgs(1). Expressing this properly needs gocritic/ruleguard, which this project doesn't currently enable. A grep-based make target follows the existing check-embed precedent and costs nothing to run.
What this adds
make check-args— mirrorscheck-embed, including thefind | xargsform so it works with BusyBox grep onalpine:3. Coversinternal/andcmd/.- Wired into
make check,lefthookpre-push, and acheck_argsCI job. - One clarifying sentence in
.gitlab/duo/mr-review-instructions.yaml. Rule 1 under "Flag handling" listedExactArgs(N),NoArgs, andRangeArgsas co-equal alternatives, so Duo had no basis to flagExactArgs(0). This is the root cause of the regression and is worth fixing regardless of the lint check.
How has this been tested?
# Passes on the current tree (0 instances remain after 9523a73c)
make check-args
# Catches the real regression from !3781
# -> internal/setup.go:53: Args: cobra.ExactArgs(0),
# -> internal/doctor.go:67: Args: cobra.ExactArgs(0),
# No false positives — verified ExactArgs(1), ExactArgs(10),
# NoArgs, and MinimumNArgs(0) are all left alone, and that the
# spaced form ExactArgs( 0 ) is still caught.
lefthook run pre-push # build, go-lint (0 issues), go-test, check-generated all pass