Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@vilmibm
Copy link
Contributor

@vilmibm vilmibm commented Jul 16, 2020

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:

  • pr create clearly errors if -t or -f are missing
  • pr create clearly errors if -w is specified
  • pr list prints more machine readable output, including draft status
  • pr view prints raw pr body + linewise metadata, including draft status
  • various human-oriented informational messages are suppressed

Closes #1297
Part of #1082
Part of #939

@vilmibm vilmibm requested a review from mislav July 16, 2020 21:17
@ampinsk
Copy link
Contributor

ampinsk commented Jul 16, 2020

@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!

@vilmibm
Copy link
Contributor Author

vilmibm commented Jul 17, 2020

@ampinsk

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.

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.

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
Comment on lines 307 to 309
if !table.IsTTY() {
table.AddField(pr.State, nil, nil)
table.AddField(prReadyState(&pr), nil, nil)
Copy link
Contributor

@mislav mislav Jul 17, 2020

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.

  1. Should we add the same columns to the default terminal output as well, for parity?
  2. 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.

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 collapsed "OPEN" and draft status into a combined "DRAFT" and moved the new column to the end of the output 👍

command/pr.go Outdated
Comment on lines 365 to 366
if web && !connectedToTerminal(cmd) {
return errors.New("--web unsupported when not attached to a tty")
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

fmt.Fprintf(stderr, "%s Approved pull request #%d\n", utils.Green("✓"), pr.Number)
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)
Copy link
Contributor

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! 🌟

@ampinsk
Copy link
Contributor

ampinsk commented Jul 17, 2020

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.

Yeah, since this is how it's presented in the UI on dotcom I think we're safe to do it this way

vilmibm added 2 commits July 20, 2020 13:04
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
@vilmibm vilmibm force-pushed the pr-scriptability branch from 1ca5ce8 to b2aca57 Compare July 20, 2020 19:19
@vilmibm vilmibm force-pushed the pr-scriptability branch from b2aca57 to fa92848 Compare July 20, 2020 20:55
@vilmibm vilmibm requested a review from mislav July 20, 2020 20:57
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.

Fantastic! Thanks for the hard work

}

out := colorableOut(cmd)
stderr := cmd.ErrOrStderr()
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good catch

Comment on lines +315 to +317
regexp.MustCompile(`#32.*New feature.*feature`),
regexp.MustCompile(`#29.*Fixed bad bug.*hubot:bug-fix`),
regexp.MustCompile(`#28.*Improve documentation.*docs`),
Copy link
Contributor

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 .*)

Copy link
Contributor Author

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.

@vilmibm vilmibm merged commit 739d66b into trunk Jul 21, 2020
@mislav mislav deleted the pr-scriptability branch August 3, 2020 08:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

pr scriptability improvements

3 participants