Conversation
Our code had an unspoken assumption that only one apiClient is created during the course of a command. Violating this assumption is fine in almost all cases, but not when we need to do a re-auth to add a new oauth scope to a user's token. There is likely a more elegant solution to the problem but until then this changes determineBaseRepo to use an existing apiClient.
This reverts commit 08e9cda.
|
I take it the I created the |
|
the -R flag is not relevant. its presence in docs for commands like this is a bug as far as i remember? either way: the arguments are file paths and relative only to the directory you're in when you run the command and not to any repositories. |
ampinsk
left a comment
There was a problem hiding this comment.
Looks awesome from my perspective! I'm curious if there would be any value to a default behavior when there are no arguments (maybe make a gist out of whatever is in the directory? though I can see that being unexpected/destructive), but I'm totally comfortable thinking about that as a follow up!
mislav
left a comment
There was a problem hiding this comment.
Good job getting this over the finish line! 🎉
| } | ||
|
|
||
| var gistCreateCmd = &cobra.Command{ | ||
| Use: `create {<filename>|-}...`, |
There was a problem hiding this comment.
Nit: since - technically can't be repeated, a more precise usage expression would be:
create {<filename>... | -}
but I would be fine with simply omitting the information about - from the usage line and make a note of it in the docs where we talk about stdin.
| RootCmd.AddCommand(gistCmd) | ||
| gistCmd.AddCommand(gistCreateCmd) | ||
| gistCreateCmd.Flags().StringP("desc", "d", "", "A description for this gist") | ||
| gistCreateCmd.Flags().BoolP("public", "p", false, "When true, the gist will be public and available for anyone to see (default: private)") |
There was a problem hiding this comment.
Nit: to simplify the language of this flag description, might we use the same language as in gh repo create?
--public Make the new repository public (default: private)
The key would be to eliminate the When true prefix since "when true" is basically implied for all boolean flags.
| var gistCreateCmd = &cobra.Command{ | ||
| Use: `create {<filename>|-}...`, | ||
| Short: "Create a new gist", | ||
| Long: `gh gist create: create gists |
There was a problem hiding this comment.
As the first sentence of Long description, we usually have a simple description of what the command does, e.g.
$ gh help pr list
List and filter pull requests in this repository
...
This can be just "Create a GitHub gist", I feel. We don't need to hardcode gh gist create since that part the user already entered in their prompt.
|
|
||
| Gists can be created from one or many files. This command can also read from STDIN. By default, gists are private; use --public to change this. | ||
|
|
||
| Examples |
There was a problem hiding this comment.
I've found this out by accident the other day: Cobra has a dedicated Example field! spf13/cobra@bf480fe
| // In the future we'd rather have the ability to detect a "reauth needed" scenario and replay | ||
| // failed requests but some short spikes indicated that that would be a fair bit of work. |
There was a problem hiding this comment.
props to explaining all this 👏
| if err != nil { | ||
| return fmt.Errorf("failed to check STDIN: %w", err) | ||
| } | ||
| if (info.Mode() & os.ModeCharDevice) != os.ModeCharDevice { |
There was a problem hiding this comment.
TIL this way of inspecting stdin 🌟 Does this work on Windows?
In my experience, the easiest way to discern whether something was piped to a command (vs a command being called on its own) is to check whether stdin is not connected to a terminal.
| return fmt.Errorf("did not understand arguments: %w", err) | ||
| } | ||
|
|
||
| info, err := os.Stdin.Stat() |
There was a problem hiding this comment.
Should we always stat stdin unconditionally, or just when the file list is empty?
| var err error | ||
| if f == "-" { | ||
| filename = fmt.Sprintf("gistfile%d.txt", i) | ||
| content, err = ioutil.ReadAll(stdin) |
There was a problem hiding this comment.
Minor: it's not strictly necessary, but I think that closing stdin after having exhausted it would be the right thing to do, especially because it would lead to a clearer error message if someone tried to pass - multiple times.
|
@wingwong I'd like to be able to edit gists from the cli too,can you please implement the feature? |
|
I believe the message for @wingkwong instead.
From: Michele Venturi <notifications@github.com>
Sent: Tuesday, June 23, 2020 5:38 AM
To: cli/cli <cli@noreply.github.com>
Cc: Wong, Wing <wing.wong@sap.com>; Mention <mention@noreply.github.com>
Subject: Re: [cli/cli] gh gist create (#981)
@wingwong<https://github.com/wingwong> I'd like to be able to edit gists from the cli too,can you please implement the feature?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#981 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQ5NM3CBNUEABZ5WW552RTRYBZWLANCNFSM4NGLKEZQ>.
|
|
@wingkwong thanks,how can I help you? 🤓 |
|
Hi, for discussing new feature ideas, such as the ability to list or edit gists, please first open a new issue for it so we can have a discussion there. I feel that this PR should only be a place for discussing the |
Fixes #397
Based on #543; moved over to new PR for CI reasons. Big ups to @wingkwong for getting it started.
This PR adds support for creating gists. You can invoke it in a few ways:
It looks like this:
Considerations
Currently we don't request the
gistscope when creating auth tokens. We didn't want another "stop every user after a release to reauth" since not every user necessarily wants gist support. This PR adds an imperfect helper,ensureScopesthat lets us prompt for re-auth in a given command.In the future the best solution would be the ability to retry failed requests when we determine they failed for valid scope reasons, but that was too much effort for now.
I'd like to add some more tests but otherwise it's ready for review.