Skip to content

Conversation

@nsmag
Copy link
Contributor

@nsmag nsmag commented Oct 11, 2022

Fixes #6400

Return empty error before starting a pager program.

Previously, these commands start pager even with empty results:

gh issue list
gh pr checks [<number> | <url> | <branch>]
gh pr list
gh run list
gh search issues [<query>]
gh search prs [<query>]
gh search repos [<query>]

For example, the output with PAGER=less shows

~
~
~
(END)

An error is printed after quitting a pager program.

no open issues in OWNER/REPO

@nsmag nsmag requested a review from a team as a code owner October 11, 2022 08:49
@nsmag nsmag requested review from mislav and removed request for a team October 11, 2022 08:49
@cliAutomation cliAutomation added the external pull request originating outside of the CLI core team label Oct 11, 2022
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! I've left a bunch of notes, mostly the same gotcha regarding checking for the presence of the exporter.

Since this change repeats similar logic across several different commands, I wonder whether we could somehow capture it from a central location, making this automatically handled even if the command didn't necessarily add these conditionals?

For example, opts.IO.StartPager() could just queue a pager for starting, but not actually start it. Then, we could replace opts.IO.Out with a Writer that, on first write, automatically starts the pager. That way, the pager will never be started for empty output, and individual commands don't have to worry about this. Just a wild idea (you don't have to actually implement this in your PR)

return err
}

checks, counts, err = aggregateChecks(pr, opts.Required)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we now do the combo of populateStatusChecks + aggregateChecks twice, would it make sense to capture both actions as a single helper function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved aggregateChecks inside of populateStatusChecks. I think it makes more sense that populateStatusChecks returns usable values than just an error.

@nsmag
Copy link
Contributor Author

nsmag commented Oct 12, 2022

Thank you for your feedback @mislav. Fixed as you requested.

When I looked at this issue I think I could fix StartPager() and solve the issue for all commands at once. But there're a lot of commands using StartPager() and some have different behaviors when dealing with empty output, for example, repo list, pr status, etc. So I decided to go with a quick fix that does not affect other commands. It'll be nice if StartPager() can handle these errors. I have no idea yet.

Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! One tiny nitpick


if len(resp.Node.StatusCheckRollup.Nodes) == 0 {
return nil
return aggregateChecks(pr, requiredChecks)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style tip: let's instead break here and allow the final return from the parent function to get reached.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

I was thinking break might change the logic because there're some statements before the final return. But I don't fully understand the whole code in this file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mislav I quickly pushed last night without running tests. It turned out that break here did break tests. I reverted the commit for now.

Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also didn't fully understand what was going on in the populateStatusChecks function, but I had a hunch that some of it was unnecessary, so I've made a pass to simplify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

external pull request originating outside of the CLI core team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Pager should not be used for empty output

3 participants