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 — mirrors check-embed, including the find | xargs form so it works with BusyBox grep on alpine:3. Covers internal/ and cmd/.
  • Wired into make check, lefthook pre-push, and a check_args CI job.
  • One clarifying sentence in .gitlab/duo/mr-review-instructions.yaml. Rule 1 under "Flag handling" listed ExactArgs(N), NoArgs, and RangeArgs as co-equal alternatives, so Duo had no basis to flag ExactArgs(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

Merge request reports

Loading
Loading