Add protocol flag for gh repo create

Describe the feature or problem you’d like to solve

When running gh repo create as part of an automation the default gh_protocol is used to set up the remote. Therefor, any subsequent git call to the remote will be using the https protocol if it was the default. However, this causes any git call to invoke a usename/password prompt which can't be filled in by the user since they're not on-session due to it being an automation.

Proposed solution

I'd like to propose the addition of a --protocol flag which can be used as follows:

gh repo create --protocol ssh

This way the more seamlessly ssh protocol is used to set up the remote which doesn't prompts the user and just uses an SSH key to authenticate. Of course, the user needs to have a SSH key set up with GitHub.

Additional context

What I'm actually trying to do is run these two commands as part of the automation to automatically set up a GitHub repository and push the main branch to it:

Part one initialises the git repo and commits the working directory

git init -q -b main .
git add .
git commit -q -m "Set up a fresh Laravel app"

Part two creates the GitHub repository and pushes the main branch to GitHub

gh repo create my-app -y --private
git push -q -u origin main

It's for the second part that I specifically need the remote to be added with the ssh protocol so the push is seamlessly and without any interruption. Note that I cannot make use of gh config set git_protocol ssh because I don't want to alter the user's protocol preference in the automation.

For full reference, this is the PR where I introduced the support for gh repo create with the Laravel installer: laravel/installer#185

Btw, just to say, I'm also open to alternative solutions here. Not hell-bend on the protocol flag. Just looking for a clean and seamless way to create a repo for the user and push the main branch onto the repo.

@driesvints

@driesvints I think I would rather see this an an environment variable that all git invocations respect than a command flag since that would entail editing all existing commands that have git functionality to use this new flag.

As a temporary solution thought, since this is an automated script, could you not retrieve the current users git_protocol preference with gh config get git_protocol and if it is https then set it to ssh and when the pushing finishes reset the git_protocol back?

As a temporary solution thought, since this is an automated script, could you not retrieve the current users git_protocol preference with gh config get git_protocol and if it is https then set it to ssh and when the pushing finishes reset the git_protocol back?

Thanks for thinking on this! I'm not sure if that's the right solution. If any of the commands fail between the calls, it could leave the user's preference in an unwanted state.

@samcoe

like @samcoe , I would also rather see this feature begin its life as an environment variable since that is consistent with the way we override other configurable things. does that work for you, @driesvints ?

Something like this?

GH_PROTOCOL=ssh gh repo create

@driesvints

@driesvints yep

Sounds perfect to me 👍

@driesvints

@driesvints Keep in mind that once #2944 gets solved, gh repo create and similar gh commands will never cause a git authentication prompt since HTTPS traffic will be guaranteed to be authenticated.

I'm not opposed to something like a --protocol flag or the GH_PROTOCOL environment variable, but in the case of gh repo create, it feels like it solving the wrong problem. If the user has indicated that they prefer https remotes, then your automated script explicitly creating ssh repositories for them goes against their preferences. So I would vote for always respecting the user's preferences, but making sure that their git fetches/pushes are authenticated even if they haven't set up a git credential helper.

Ref. #2189

@mislav

@mislav I fully agree with you here. The main problem that I'm trying to prevent is users getting prompted for authentication when they're already properly authenticated through the GitHub CLI. So if this can be solved differently and without a flag then that's fine by me 👍

Feel free to close this if you want.

@driesvints

@driesvints Which operations other than gh repo create does your script do that may trigger git network requests? Knowing your script's needs would be helpful to us for ensuring that we can properly authenticate git operations. Thank you!

Only gh repo create from this PR: https://github.com/laravel/installer/pull/185/files#diff-80009ae2f5723cd34d5f864eb4cc5e9a09425ad1ba21dca95f0e32bfb7968e83R268

@driesvints

@driesvints Thank you! It looks like you git push to the created repo right after. I wonder if we could provide some kind of functionality from gh to ensure all your pushes from scripts are authenticated even if the person who is running the script is not set up with git credential caching.

For now, you could do a git push like this:

GIT_TERMINAL_PROMPT=0 git -c credential.helper= -c credential.helper='!gh auth git-credential' push

Yes, it's verbose, but it's relatively safe to do and will ensure that as long as gh is authenticated (either via ~/.config/gh/hosts.yml or GITHUB_TOKEN), git pushes will work as well. No need to switch to ssh remotes just to avoid authentication prompts. The addition of GIT_TERMINAL_PROMPT=0 ensures that when gh is not authenticated, the git command will error out instead of prompt for credentials. This makes it suitable for scripts.

@mislav

@mislav thanks a lot for that. I've sent in a PR to do just that: laravel/installer#191

I think related to this entire thread is that it would be cool if gh repo create could also push the HEAD branch that was active at the time of the repo create. That would also solve a lot for us.

Something like gh repo create --with-head, gh repo create --with-branch or gh repo create -b?

@driesvints

@driesvints I do like the create-and-push idea! You are welcome to submit that as a separate feature request.

BTW we can still consider the per-invocation --protocol flag or environment variable, but I just didn't think it was a good fit for this exact use case. We do want to improve how we handle git authentication and have flexible functionality to meet our users' needs, so all this feedback and extra perspective that you're providing is is great. Thank you! ✨

@mislav

@mislav done: #3209

You're welcome :)

@mislav

@mislav we unfortunately had to revert your suggestion for the installer because it would only work on WSL for Windows. Our installer is intended to work for Windows in general. So we're back at square one I'm afraid.

@driesvints

@driesvints Thanks for letting me know. I don't see why that approach wouldn't work outside of WSL, but I must admit I haven't tested it on Windows. I will report back with my findings

Navigation Menu

Repository navigation

Add protocol flag for gh repo create #3088

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add protocol flag for gh repo create #3088

Description

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Activity

driesvints commented on Mar 5, 2021

samcoe commented on Mar 5, 2021

driesvints commented on Mar 5, 2021

vilmibm commented on Mar 8, 2021

driesvints commented on Mar 8, 2021

vilmibm commented on Mar 8, 2021

driesvints commented on Mar 8, 2021

mislav commented on Mar 10, 2021

driesvints commented on Mar 10, 2021

mislav commented on Mar 10, 2021

driesvints commented on Mar 10, 2021

mislav commented on Mar 11, 2021

driesvints commented on Mar 12, 2021

mislav commented on Mar 12, 2021

driesvints commented on Mar 12, 2021

driesvints commented on Mar 16, 2021

mislav commented on Mar 17, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions