Repository navigation
Improvements to label list #5489
Description
Activity
On a related note, should at least a
label removecommand as well. Alabel editmight also be useful, but alabel create --forcewill accomplish the same thing.I responded inline regarding these proposals, so I will just briefly summarize here.
-
I am not convinced that removing the default limit is the right direction for a couple reasons.
-
I am onboard with adding
--orderand--searchflags with functionality that is backed by the API. Adding this functionality makes the default limit more valuable IMO. -
The labels are ordered by created at date when returned from the API.
-
A
label removecommand makes sense to me butlabel editseems redundant withlabel create --force. Perhaps that is okay though sincelabel editis more discoverable and explicit.
-
- added a commit that references this issue
on Apr 22, 2022 - added 2 commits that reference this issue
on Apr 25, 2022
Based on comments, I think there's a few improvements we should make to
label list:Do not limit results by default. There seems to be no customer value unless they explicitly want to limit results.
To clarify, it is used as the page size and does support paging, but lines 67-69 of this block of code should be removed:
cli/pkg/cmd/label/list/http.go
Lines 65 to 70 in c99c47f
One reason they might want to limit results is to filter the list, much like you can filter issues or PRs. Like heaths/gh-label we could either tag an optional argument for the filter term, or a
--searchparameter likeissue listhas for consistency. The former would only be breaking if someone actually expected an error with an additional arg, but that seems like an impractical test. The latter would be consistent withissue listandpr list, however.Sort results by default. A large list of unsorted labels is difficult to read and find what you want. The order returned is also not documented and should not be relied on.