The HTTPS credential behavior introduced in #2449 is only effective after the user has completed the interactive gh auth login flow. However, if someone does this in a script:
GH_TOKEN="..." gh repo clone <repo>
The internal git clone operation is not guaranteed to use the supplied token. Instead, the usual git credential mechanism is used, so if this was run in an isolated environment such as a CI job, the clone command would most likely fail on prompting for username+password.
Commands that can currently result in a git network operation:
We could try to add extra flags to those invocations of git to configure that gh should be used unconditionally as a credential helper. Something like:
git -c 'credential.helper=' \
-c 'credential.https://<GH_HOST>.helper=' \
-c 'credential.helper=!gh auth git-credential' \
clone ...
The HTTPS credential behavior introduced in #2449 is only effective after the user has completed the interactive
gh auth loginflow. However, if someone does this in a script:The internal
git cloneoperation is not guaranteed to use the supplied token. Instead, the usual git credential mechanism is used, so if this was run in an isolated environment such as a CI job, the clone command would most likely fail on prompting for username+password.Commands that can currently result in a git network operation:
repo clone-git clonerepo fork-git remote add -fpr create-git remote add -f,git pushWe could try to add extra flags to those invocations of
gitto configure thatghshould be used unconditionally as a credential helper. Something like: