git clone - échouer au lieu de demander des informations d'identification

14

Lors du clonage de référentiels git dans des outils automatisés - frontaux Web, systèmes CI, parfois l'invocation du clone git ouvre une invite demandant le nom d'utilisateur et le mot de passe (par exemple, lors du clonage d'un référentiel Github inexistant ou sur un nouveau nœud, les clés ssh manquent ).

Comment faire git échouer (de préférence avec un message d'erreur sensible et un code de sortie) au lieu d'attendre que le processus serveur lui donne un nom d'utilisateur et un mot de passe?

git automation

— Tin Tvrtković
source

Nous avons mis en place un Jenkins multi-serveur, qui attend de manière ennuyeuse une invite jusqu'à ce qu'il soit tué s'il s'exécute sur un nouveau serveur sans les clés ssh - un moyen de configurer qu'il échouera simplement avec un message et un code de sortie non nul serait sois utile.

— Danny Staple

Si un mode "batch" catch all pouvait également être utilisé pour interdire l'invite pour les clés d'hôte - ce serait l'idéal.

— Danny Staple

Ces deux éléments sont liés - en essayant de les assembler - serverfault.com/questions/61915/… , stackoverflow.com/questions/7772190/… .

— Danny Staple

15

Dans la version 2.3 de git, il existe une variable d'environnement GIT_TERMINAL_PROMPTqui, lorsqu'elle est définie sur 0, désactivera la demande d'informations d'identification.

Vous pouvez obtenir plus d'informations à ce sujet dans man git(après la mise à jour vers la version git 2.3) ou dans cet article de blog sur github .

Exemples:

git clone https://github.com/some/non-existing-repo demandera un nom d'utilisateur et un mot de passe
GIT_TERMINAL_PROMPT=0 git clone https://github.com/some/non-existing-repo échouera sans demander le nom d'utilisateur et le mot de passe

Frustrant d'être de retour ici avec un clone https git, sur un serveur el7 avec git 1.8. Aller vérifier si la mise à jour vers 2.0 à partir de l'autre référentiel est une option pour cela.

— Danny Staple,

0

Si vous utilisez l'authentification ssh et sous linux, vous pouvez créer un remplacement de commande ssh pour le désactiver.

Créez un fichier appelé "sshnoprompt.sh" avec:

ssh -oBatchMode=yes $@

Rendre ce fichier exécutable avec chmod +x sshnoprompt.sh

Puis lors du démarrage de git:

GIT_SSH="sshnoprompt.sh" git clone foo@dummyserver:not_a_repo

Et il n'autorisera aucune invite ou question interactive git - il ne devrait pas pouvoir demander quoi que ce soit à l'utilisateur.

— Danny Staple
source

0

Travailler à partir de la version 1.8.3.1 de git;

git clone -c core.askPass $echo url/or/path/to/git/repo

La configuration core.askPassfonctionne en passant le contrôle de la gestion des informations d'identification au programme susmentionné. Cependant, étant donné que $echoje ne peux rien faire sauf la sortie, la tentative de clonage échoue rapidement et la redirection bash respective s'applique. Ce code est uniquement invoqué dans le cas où le référentiel git se trouve être privé, et transmet une sortie d'erreur indiquant que l'authentification a échoué pour le référentiel particulier. Vous pouvez tester cela par rapport au https://github.com/git/gitréférentiel public par rapport à un référentiel privé que vous connaissez.

Pour adoucir l'accord, vous n'auriez même pas besoin de référencer un programme comme echoen premier lieu. Le simple fait de passer la configuration git -c core.askPasssans entrée suivante entraînerait toujours un échec dans le cas où le référentiel se trouve être privé car le code ne saura pas vers quel programme décharger la gestion des informations d'identification. Bien que ce soit certainement une méthode plus ancienne et plus simple que les autres mentionnées ici, je ne sais pas si elle aura le même effet dans les anciennes versions de git.

— Jouster500
source

Vous avez quelque peu raison tout en vous trompant. Tout d'abord, dans votre cas, il $echos'agit d'une référence de variable qui (étant non définie) se développe en chaîne vide, donc elle n'a aucun sens. Si vous y mettez echo(sans le signe dollar), ce serait également incorrect car il serait interprété comme l'emplacement du référentiel. Il faudrait que ce soit -c core.askPass=echo.

— Michał Górny

-1

Selon la façon dont vous exécutez git, rediriger stdin ou stdout afin qu'ils ne soient pas connectés aux terminaux empêchera git de demander des détails et provoquera simplement une erreur.

Cela vous permettrait également de signaler des erreurs (ou au moins des journaux) au service Web.

— Matthew Steeples
source

Comment pourrais-je faire exactement cela? Essayer d'accomplir cela dans Bash d'abord, les deux </dev/nullet nohup .. &ne semblent pas fonctionner.

— Tin Tvrtković

Cette réponse n'est pas utile sans un exemple spécifique sur la façon d'y parvenir. Surtout que les méthodes «évidentes» ne fonctionnent pas, comme mentionné ci-dessus.

— Michał Górny

@ MichałGórny Je n'avais pas vu la question OPs il y a quelques années, mais il n'y avait pas assez d'informations dans la question (OS, Toolset) pour pouvoir y répondre. Redirection de stdin et stdout. Git a beaucoup changé depuis que la question a été posée (sous Windows par exemple, il affiche des boîtes de dialogue externes pour les informations d'identification si vous vous connectez à Azure DevOps), il est donc préférable d'utiliser la variable d'environnement répertoriée dans la réponse principale

— Matthew Steeples