Hello! :octocat:
Today I was doing the setup of a git automation inside a Docker container using hub and I ran into something that seems a bug.
Since the problem is related to an authentication problem let me give you some context before to talk about the error I have encountered.
In order to perform all the operations, I was using a personal token as mentioned in hub's man page
The part of the script that was configuring hub was looking like this:
hub config --global hub.protocol https
hub config --global user.email $email
hub config --global user.name $username
export GITHUB_TOKEN=$token
My automation was trying to perform the following operations on a public repository:
The problem was that the push and the pull-request commands both gave me this (meaningless) error:
After a long struggling, I've then found a solution that seems a bit wired to me.
In order to be able to push on my fork I was needed to change this:
hub remote set-url upstream https://github.com/$owner/$repo.git
hub remote set-url origin https://github.com/$username/$repo.git
to this:
hub remote set-url upstream https://$token:[email protected]/$owner/$repo.git
hub remote set-url origin https://$token:[email protected]/$username/$repo.git
Why the $GITHUB_TOKEN environmental variable isn't enough in this situation?
The $GITHUB_TOKEN
env var enables me to create a new repo (forking) on my account but does not give me the possibility to push on the same? Am I missing something?
Below you can find the "complete" script that lets you reproduce the error:
# You must set these variables: $email, $username, $token, $repo, $owner
hub config --global hub.protocol https
hub config --global user.email $email
hub config --global user.name $username
export GITHUB_TOKEN=$token
# Clones the repo
rm -rf ./$repo/
hub clone $owner/$repo
cd ./$repo/
# Fork the repo
hub fork
# Update remotes
hub remote rename origin upstream
hub remote rename $username origin
hub remote -v
hub pull --all
# Add something to the repo
echo "🌈" > 42
git add 42
# Push on our fork
hub push origin -f
# ^-- The push throws the error
# You must set these variables: $email, $username, $token, $repo, $owner
hub config --global hub.protocol https
hub config --global user.email $email
hub config --global user.name $username
export GITHUB_TOKEN=$token
# Clones the repo
rm -rf ./$repo/
hub clone $owner/$repo
cd ./$repo/
# Fork the repo
hub fork
# Update remotes
hub remote rename origin upstream
hub remote rename $username origin
hub remote set-url upstream https://$token:[email protected]/$owner/$repo.git
hub remote set-url origin https://$token:[email protected]/$username/$repo.git
hub remote -v
hub pull --all
# Add something to the repo
echo "🌈" > 42
git add 42
# Push on our fork
hub push origin -f
FROM alpine:latest
RUN echo http://dl-cdn.alpinelinux.org/alpine/edge/testing >> /etc/apk/repositories
RUN apk update
RUN apk add git hub bash
# Copy the script
COPY script.sh .
RUN bash pr.sh
If interested you can find the whole script here.
Thank you!
Hi thank you for the incredibly detailed report! ✨ ✨
This is something that is often a cause of confusion for hub users: when doing operations such as hub clone
or hub fork … hub push
, there are two authentication methods to GitHub in play, and they are in no way related! One may be fine, but the other one can be misconfigured (or vice versa).
The first authentication method is the one git uses for pushing git commits to repos or cloning/fetching from private repos, and is _in no way related or affected by hub_. There are basically two authentication strategies for git operations:
[email protected]:simonepri/project.git
. This can be set up by generating a key using ssh-keygen
and adding the public key to your GitHub account. See https://help.github.com/articles/connecting-to-github-with-ssh/https://github.com/simonepri/project.git
. Git will either obtain the username/password combo from the configured credentials helper (see git help credentials
) or prompt for them interactively in the terminal. For added security, it's recommended to use a Personal Access Token in place of your actual GitHub password (this is even enforced when Two-Factor Authentication is enabled for your account). See https://help.github.com/articles/caching-your-github-password-in-git/ https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/The second authentication method is the one hub uses to access the GitHub API. This is completely separate from git protocol authentication described above, for these reasons:
github.com
, it can't be used by hub beause GitHub API can only be accessed over HTTPS.repo
scope that the tokens for git cloning are usually created with.So you see, when you do hub clone owner/project
, both authentication methods kick in: first hub checks the GitHub API, then git uses its own authentication method to fetch the repo. When hub users get an authentication error, they are often confused as to why they are getting it, because they have either sorted out git authentication or hub authentication, but they don't realize they need to configure both.
Ideas how to improve the user-friendliness of this is very welcome! Also see plans for #225.
Hi @mislav,
Thank you for the reply!
I think there are a lot of things to improve the user-friendliness, but maybe this issue is not the best place to discuss about.
My impression, is that using hub to achieve some simple operation seems just over-complicated.
For example, I would expect something like this to work:
hub auth $GITHUB_TOKEN <--- This should take care of all the stuffs related to the auth
hub fork $owner/$repo <--- This should clone, fork and set remotes correctly
# some edits
hub push <--- Should work without any type of configs if the token have enough rights.
Anyway let's talk about the auth error:
git should not be transparent while using hub. I mean. Hub should predict misconfigurations instead of letting git fail in strange ways.
I believe that hub should provide the same easy-to-use experience of the GitHub website inside the terminal.
Can you show me what is correct way to setup both hub and git authentications using the Personal Access Token ($GITHUB_TOKEN)?
I did not found any good example.
The correct way to auth with both git and hub:
For git HTTPS auth, you want to configure the credentials helper (this is platform-specific) to store the username/token combo. This is an example how to do it with osxkeychain
on Mac OS
For hub, doing export GITHUB_TOKEN=$token
and configuring hub to always use HTTPS is enough: git config --global hub.protocol https
.
What about adding those information somewhere inside the hub's documentation?
Also I believe that the community would appreciate if we add some examples on how to perform some basic operations (authentication, create a fork, open a pull-request, etc) with hub.
In case I would be happy to help.
Adding extra documentation about this would be great, but actually implementing something like hub auth $GITHUB_TOKEN
that you've proposed would be even better. See #225 for plans to make a command like that. In the future, hub should have a dedicated auth
command, switch to HTTPS protocol by default, and help you set up the git credential helper in case you haven't already.
Any help around implementing this would be welcome!
Closing this in favor of the referenced issue. Authentication should be easier and more friendly once a dedicated command for that is written.
This is something that is often a cause of confusion for hub users:
:beach_umbrella: very true words indeed! :1st_place_medal:
Working in a jenkinsfile, the only thing that worked to be able to push changes back to the origin was this bit of groovy & embedded shell script:
SOURCE_REPO="eclipse/che"
GITHUB_TOKEN="mytokenhere"
sh '''
export GITHUB_TOKEN=''' + GITHUB_TOKEN + ''' # echo "''' + GITHUB_TOKEN + '''"
git config --global hub.protocol https
git remote set-url origin https://\$GITHUB_TOKEN:[email protected]/''' + SOURCE_REPO + '''.git
git commit ...
git push
'''
Thanks for the hint!
Most helpful comment
Hi thank you for the incredibly detailed report! ✨ ✨
This is something that is often a cause of confusion for hub users: when doing operations such as
hub clone
orhub fork … hub push
, there are two authentication methods to GitHub in play, and they are in no way related! One may be fine, but the other one can be misconfigured (or vice versa).The first authentication method is the one git uses for pushing git commits to repos or cloning/fetching from private repos, and is _in no way related or affected by hub_. There are basically two authentication strategies for git operations:
[email protected]:simonepri/project.git
. This can be set up by generating a key usingssh-keygen
and adding the public key to your GitHub account. See https://help.github.com/articles/connecting-to-github-with-ssh/https://github.com/simonepri/project.git
. Git will either obtain the username/password combo from the configured credentials helper (seegit help credentials
) or prompt for them interactively in the terminal. For added security, it's recommended to use a Personal Access Token in place of your actual GitHub password (this is even enforced when Two-Factor Authentication is enabled for your account). See https://help.github.com/articles/caching-your-github-password-in-git/ https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/The second authentication method is the one hub uses to access the GitHub API. This is completely separate from git protocol authentication described above, for these reasons:
github.com
, it can't be used by hub beause GitHub API can only be accessed over HTTPS.repo
scope that the tokens for git cloning are usually created with.So you see, when you do
hub clone owner/project
, both authentication methods kick in: first hub checks the GitHub API, then git uses its own authentication method to fetch the repo. When hub users get an authentication error, they are often confused as to why they are getting it, because they have either sorted out git authentication or hub authentication, but they don't realize they need to configure both.Ideas how to improve the user-friendliness of this is very welcome! Also see plans for #225.