docs: clarify --all and --per-page pagination behavior

Summary

Updates flag descriptions to clarify pagination behavior in glab repo list (per issue #8325 (closed)) and applies the same Maximum: 100. annotation to --per-page across every command that exposes it against a REST endpoint, for consistency.

glab repo list (issue #8325 (closed) scope)

  • --all: clarify that this only removes the ownership filter — results are still paginated and the command does not loop pages. Original wording was misleading (users expected --all to enumerate every project).
  • --per-page: document the GitLab REST API maximum of 100.

Cross-command rollout

--per-page description gets Maximum: 100. appended for the following commands:

ci/delete, ci/list, cluster/agent/list, deploy-key/list, incident/list & incident/view, issue/list & issue/view, iteration/list, label/list, milestone/list, mr/list, mr/view, release/list, repo/clone, repo/contributors, repo/search, runner/jobs, runner/list, schedule/list, securefile/list, ssh-key/delete, ssh-key/get, ssh-key/list, todo/list, user/events, variable/export, variable/list, work-items/list.

ci/list previously had bespoke wording (Defaults to the GitLab API default (20).); dropped for consistency with the auto-appended (default N) style used elsewhere.

Verification

  • GitLab REST API docs confirm per_page caps at 100 universally — no per-endpoint exceptions: https://docs.gitlab.com/api/rest/#pagination
  • Comment-limit --per-page flags in mr view and issue view flow through to REST notes/discussions endpoints (same cap).
  • work-items list already enforces the 100 cap in CLI code (list.go:135).
  • Generated docs regenerated via make gen-docs.
  • go build ./... clean; tests pass on project/list, mr/view, workitems/list.

Closes #8325 (closed)

Edited by Brendan Lynch

Merge request reports

Loading