New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pr command scriptability improvements #1373
Conversation
@vilmibm thanks for this! Is ready status in addition to overall PR state? I think of draft status as alongside general PR state, so state can be Draft, Open, Merged, Closed and "reviewability" can be inferred from that, but I might be missing some context! |
That makes total sense and we're communicating that right now with color (gray for open+draft, green for open+ready, red for closed, purple for merged). I felt weird for this machine readable output since "draft" is not a PR state that the API can filter by. State is either open, closed, or merged; draft is this weird orthogonal status. I wondered if someone integrating this in a script would expect to handle this data in the same way the API does: where "draft" and "state" are two separate concepts. If you think it makes sense to collapse those concepts I can report on open+draft PRs as having a DRAFT state instead of OPEN. I don't have any strong feelings here other than it should be possible in the machine readable state to determine draft status so I'm open to whatever approach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you think it makes sense to collapse those concepts I can report on open+draft PRs as having a DRAFT state instead of OPEN.
I would vote for this approach as well! ✋
command/pr.go
Outdated
if !table.IsTTY() { | ||
table.AddField(pr.State, nil, nil) | ||
table.AddField(prReadyState(&pr), nil, nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two extra columns when output is redirected makes this output to be radically different from the human-readable one. However, I agree that we used to use color to communicate open/closed/merged/draft states and that we now have to communicate that using words as well.
- Should we add the same columns to the default terminal output as well, for parity?
- Would we consider adding the columns at the end instead of in the middle, to avoid breaking existing scripts? We're in beta, so technically we could make breaking changes, but if could avoid doing that it would be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I collapsed "OPEN" and draft status into a combined "DRAFT" and moved the new column to the end of the output 👍
command/pr.go
Outdated
if web && !connectedToTerminal(cmd) { | ||
return errors.New("--web unsupported when not attached to a tty") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we allow --web
in scripting scenarios? Since people can set BROWSER
environment variable to be the tool of their choice, it might be useful to allow it. Is there some part of --web
experience that requires an interactive terminal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm; I suppose we could. I think my brain was interpreting "non-tty" as "human not present" but they might want this tool to open things in a browser as part of a larger script.
I'll undo all that here and in the other PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense! My brain was accidentally superimposing "non-tty" with "no human at computer" but naturally that wouldn't be the case in a script that composes gh. I restored this behavior but did suppress the informational printing if not connected to a tty.
case api.ReviewRequestChanges: | ||
fmt.Fprintf(out, "%s Requested changes to pull request #%d\n", utils.Red("+"), pr.Number) | ||
fmt.Fprintf(stderr, "%s Requested changes to pull request #%d\n", utils.Red("+"), pr.Number) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice that this is now stderr! 🌟
Yeah, since this is how it's presented in the UI on dotcom I think we're safe to do it this way |
This commit improves behavior and error handling for pr commands when run unattached to a tty. - error if pr create and no -t/-f - error if pr create and -w - machine readable pr list - machine readable pr view - various cleanup of informational messages
1ca5ce8
to
b2aca57
Compare
b2aca57
to
fa92848
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic! Thanks for the hard work
command/pr_review.go
Outdated
@@ -106,15 +109,15 @@ func prReview(cmd *cobra.Command, args []string) error { | |||
return fmt.Errorf("did not understand desired review action: %w", err) | |||
} | |||
|
|||
out := colorableOut(cmd) | |||
stderr := cmd.ErrOrStderr() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this should be made "colorable" so Windows can properly output colors on stderr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch
regexp.MustCompile(`#32.*New feature.*feature`), | ||
regexp.MustCompile(`#29.*Fixed bad bug.*hubot:bug-fix`), | ||
regexp.MustCompile(`#28.*Improve documentation.*docs`), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing these regexps makes me think that we could benefit in the future from an assertion matcher that first strips ANSI escape sequences. Then we can assert expected output in an exact manner (i.e. without .*
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I think that would be wise.
This PR came out of the research in #940 and consists of several small changes to pr commands that
make them more amenable to scripting.
In this PR, when run unattached to a TTY:
Closes #1297
Part of #1082
Part of #939