Repository navigation
Add protocol flag for gh repo create #3088
Description
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 sshThis 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 mainIt'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
Activity
driesvints commentedon Mar 5, 2021
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.
samcoe commentedon Mar 5, 2021
@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_protocolpreference withgh config get git_protocoland if it is https then set it to ssh and when the pushing finishes reset thegit_protocolback?driesvints commentedon Mar 5, 2021
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.
vilmibm commentedon Mar 8, 2021
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 ?
driesvints commentedon Mar 8, 2021
Something like this?
vilmibm commentedon Mar 8, 2021
@driesvints yep
driesvints commentedon Mar 8, 2021
Sounds perfect to me 👍
mislav commentedon Mar 10, 2021
@driesvints Keep in mind that once #2944 gets solved,
gh repo createand 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
--protocolflag or theGH_PROTOCOLenvironment variable, but in the case ofgh repo create, it feels like it solving the wrong problem. If the user has indicated that they preferhttpsremotes, then your automated script explicitly creatingsshrepositories 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
driesvints commentedon Mar 10, 2021
@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.
mislav commentedon Mar 10, 2021
@driesvints Which operations other than
gh repo createdoes 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!driesvints commentedon Mar 10, 2021
Only
gh repo createfrom this PR: https://github.com/laravel/installer/pull/185/files#diff-80009ae2f5723cd34d5f864eb4cc5e9a09425ad1ba21dca95f0e32bfb7968e83R268mislav commentedon Mar 11, 2021
@driesvints Thank you! It looks like you
git pushto the created repo right after. I wonder if we could provide some kind of functionality fromghto 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:
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.ymlor GITHUB_TOKEN), git pushes will work as well. No need to switch to ssh remotes just to avoid authentication prompts. The addition ofGIT_TERMINAL_PROMPT=0ensures that when gh is not authenticated, the git command will error out instead of prompt for credentials. This makes it suitable for scripts.driesvints commentedon Mar 12, 2021
@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 createcould 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-branchorgh repo create -b?mislav commentedon Mar 12, 2021
@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
--protocolflag 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! ✨driesvints commentedon Mar 12, 2021
@mislav done: #3209
You're welcome :)
driesvints commentedon Mar 16, 2021
@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.
mislav commentedon Mar 17, 2021
@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