PR listing: add --fields & expose additional fields #415
Merged
6543
merged 9 commits from justusbunsi/tea:feature/show-labels-for-pulls
into master
1 year ago
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'justusbunsi/tea:feature/show-labels-for-pulls'
Deleting a branch is permanent. It CANNOT be undone. Continue?
This PR adds the
--fields
flag totea pr ls
(#342), and exposes more fields specific to thePullRequest
type:Thanks!
#400 also proposes to implements this, though in a different way.
As described in that PR, there's problems with that approach, and currently I tend to remove the
tea pr ls
changes from #400, instead aiming to add more filters to the API in Gitea & SDK in the long run, in the end favoring this PR.As per Discord chat with @noerw: I added support for additional fields to make it more similar to the
issues
command. Are there any other fields that would be nice to have for PRs?Also, I'm not totally happy with these changes. The formatting related code for issues and pulls are ~100% duplicates.
Show labels for pullsto Support additional fields for pulls 1 year agofor _, label := range x.Labels {
if _, ok := labelMap[label.ID]; !ok {
labelMap[label.ID] = formatLabel(label, !isMachineReadable(output), "")
labelMap[label.ID] = label
the idea here was to do the work of
formatLabel()
for each label only once. nowlabelMap
does not really serve a purpose.but I guess this map was premature optimization anyway, as the total label count for a call of
printIssues
is unlikely to exceed 1000 individual labels anyway, in most cases more like 20-50.so I'd remove labelMap and this loop
Wouldn't it be counter productive to remove such performance improvement, even if it's currently a possible
premature
one? I thought it would be good to have all theformat<...>()
function calls encapsulated insideFormatField
. In fact, I didn't realize the performance optimization taking place here even though there is a comment mentioning it. 😬If you don't mind, I'd rather keep this label map for both issues and pulls.
We could partially integrate #258 in this PR.
conflicts?
is already represented by the additional fieldmergeable
.base/head branch
are available and only needs to be added to the optional fields.Regarding
reviews
(count) we'd need to do an extra rest request to retrieve all reviews of that PR to count them.Support additional fields for pullsto WIP: Support additional fields for pulls 1 year agoWIP: Support additional fields for pullsto Support additional fields for pulls 1 year agoSupport additional fields for pullsto PR listing: add --fields & expose additional fields 1 year ago3cf084cb96
into master 1 year agoReviewers
3cf084cb96
.