Quelle est la bonne façon «d'aller chercher» un référentiel privé?


143

Je cherche le moyen de $ go gettravailler avec un référentiel privé, après de nombreux essais sur Google.

Le premier essai:

$ go get -v gitlab.com/secmask/awserver-go
Fetching https://gitlab.com/secmask/awserver-go?go-get=1
https fetch failed.
Fetching http://gitlab.com/secmask/awserver-go?go-get=1
Parsing meta tags from http://gitlab.com/secmask/awserver-go?go-get=1 (status code 200)
import "gitlab.com/secmask/awserver-go": parse http://gitlab.com/secmask/awserver-go?go-get=1: no go-import meta tags
package gitlab.com/secmask/awserver-go: unrecognized import path "gitlab.com/secmask/awserver-go

Oui, il n'a pas vu les balises meta car je ne pouvais pas savoir comment fournir les informations de connexion.

Le deuxième essai:

Suivez https://gist.github.com/shurcooL/6927554 . Ajoutez la configuration à .gitconfig.

[url "ssh://git@gitlab.com/"]
    insteadOf = https://gitlab.com/
$ go get -v gitlab.com/secmask/awserver-go --> not work
$ go get -v gitlab.com/secmask/awserver-go.git --> work but I got src/gitlab.com/secmask/awserer-go.git

Oui cela fonctionne mais avec l' .gitextension avec le nom de mon projet, je peux le renommer en original mais le faire à chaque fois $ go getn'est pas si bon, y a-t-il une autre façon?


2
une fois que vous avez suivi la réponse ci-dessous, assurez-vous d'exporter GOPRIVATEégalement. par exempleexport GOPRIVATE="github.com/steelx/that-private-repo"
STEEL

Réponses:


91

Vous avez une chose à configurer. L'exemple est basé sur GitHub mais cela ne devrait pas changer le processus:

$ git config --global url.git@github.com:.insteadOf https://github.com/
$ cat ~/.gitconfig
[url "git@github.com:"]
    insteadOf = https://github.com/
$ go get github.com/private/repo

Déjà fait cela, en fait ce n'est qu'une seule configuration à faire, la catcommande est juste pour vérifier.
secmask

1
Le seul inconvénient est que vous ne pouvez pas avoir une configuration différente pour chaque hôte (par exemple si vous utilisez plusieurs fournisseurs) sans modifier la configuration globale de git à chaque fois. Ensuite, il est préférable de spécifier ceci sur «ssh-level» comme décrit: stackoverflow.com/questions/27500861/…
Joachim

1
Je souhaite que cela soit voté plus haut. Même pour les dépôts publics, je préfère utiliser ssh dans la mesure du possible, car deux facteurs rendent l'authentification du mot de passe difficile. Cela corrige tous les dépôts github en urls ssh. Merci!
captncraig

53

La bonne façon est de placer manuellement le référentiel au bon endroit. Une fois le référentiel là, vous pouvez utiliser go get -upour mettre à jour le package et l' go installinstaller. Un package nommé

github.com/secmask/awserver-go

entre dans

$GOPATH/src/github.com/secmask/awserver-go

Les commandes que vous tapez sont:

cd $GOPATH/src/github.com/secmask
git clone git@github.com:secmask/awserver-go.git

5
@secmask go getest conçu comme un outil pour le cas courant. L'équipe Go a explicitement décidé de ne pas ajouter de configurabilité afin que les gens adhèrent aux normes au lieu de déployer leur propre cruft. Il n'a jamais été fait pour le cas que vous avez (c'est-à-dire les dépôts privés).
fuz

@Shudipta Veuillez arrêter avec les modifications. Les questions semblent pires comme vous le souhaitez.
fuz

Belle documentation. Sauvé ma vie.
Anish Varghese

34

J'ai eu un problème avec l' go getutilisation du dépôt privé sur gitlab de notre société. J'ai perdu quelques minutes à essayer de trouver une solution. Et j'ai trouvé celui-ci:

  1. Vous devez obtenir un jeton privé sur:
    https://gitlab.mycompany.com/profile/account

  2. Configurez votre git pour ajouter un en-tête supplémentaire avec votre jeton privé:

    $ git config --global http.extraheader "PRIVATE-TOKEN: YOUR_PRIVATE_TOKEN
  3. Configurez votre git pour convertir les requêtes de http en ssh :

    $ git config --global url."git@gitlab.mycompany.com:".insteadOf "https://gitlab.mycompany.com/"
  4. Enfin, vous pouvez utiliser votre go getnormalement:

    $ go get gitlab.com/company/private_repo

3
Utilisation intéressante de http.extraheader. +1
VonC

29
enverra --globalégalement votre jeton privé à un autre serveur git au cas où vous utiliseriez de nombreux repo? un risque sécurisé?
secmask

Quelqu'un a-t-il un commentaire à ce sujet? Je pense qu'il l'enverra au repo public github lorsque nous irons les chercher
Hemu

13

Tout ce qui précède n'a pas fonctionné pour moi. Le clonage du dépôt fonctionnait correctement mais j'obtenais toujours une unrecognized importerreur.

En ce qui concerne Go v1.13, j'ai trouvé dans la doc que nous devrions utiliser la variable env GOPRIVATE comme suit :

$ GOPRIVATE=github.com/ORGANISATION_OR_USER_NAME go get -u github.com/ORGANISATION_OR_USER_NAME/REPO_NAME

10

Si vous avez déjà git en utilisant SSH, cette réponse d' Ammar Bandukwala est une solution de contournement simple:


$ go getutilise en gitinterne. Les doublures suivantes vont créer gitet par conséquent $ go getcloner votre paquet via SSH.

Github:

$ git config --global url."git@github.com:".insteadOf "https://github.com/"

BitBucket:

$ git config --global url."git@bitbucket.org:".insteadOf "https://bitbucket.org/"

10

Cela ressemble au problème GitLab 5769 .

Dans GitLab, puisque les référentiels se terminent toujours par .git, je dois spécifier .gità la fin du nom du référentiel pour le faire fonctionner, par exemple:

import "example.org/myuser/mygorepo.git"

Et:

$ go get example.org/myuser/mygorepo.git

On dirait que GitHub résout ce problème en ajoutant ".git".

Il est censé être résolu dans « Ajout de la prise en charge de la récupération du référentiel de Go. # 5958 ”, à condition que les bonnes balises Meta soient en place .
Bien qu'il y ait toujours un problème pour Go lui-même: « cmd/go: go get ne peut pas découvrir la balise meta dans les documents HTML5 ».


En fait, ils (et d'autres) ont déjà pris en charge les balises méta, mais cela ne fonctionne que pour le dépôt public (où go getpeut voir les balises méta sans connexion)
secmask

@secmask, c'est pourquoi vous utilisez ssh: pour fournir les informations d'identification de cette façon.
VonC

oh, cette option juste, je peux utiliser http, https mais la go getcommande ressemblera à go get gitlab.com/secmask/awserver-go.git.git(demandera l'authentification de base http), qui ne semblent pas bonnes aussi.
secmask

8

Générez un jeton github oauth ici et exportez votre jeton github en tant que variable d'environnement:

export GITHUB_TOKEN=123

Définissez git config pour utiliser l'url d'authentification de base:

git config --global url."https://$GITHUB_TOKEN:x-oauth-basic@github.com/".insteadOf "https://github.com/"

Maintenant, vous pouvez go getvotre repo privé.


5

J'ai créé un ssh-config spécifique à l'utilisateur, de sorte que mon utilisateur se connecte automatiquement avec les informations d'identification et la clé correctes.

J'avais d'abord besoin de générer une paire de clés

ssh-keygen -t rsa -b 4096 -C "my@email.here"

et l'a enregistré par exemple ~/.ssh/id_my_domain. Notez qu'il s'agit également de la paire de clés (privée et publique) que j'ai connectée à mon compte Github, donc la mienne est stockée dans ~/.ssh/id_github_com.

J'ai ensuite créé (ou modifié) un fichier appelé ~/.ssh/configavec une entrée:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_github_com

Sur un autre serveur, le "ssh-url" est admin@domain.com:username/private-repo.gitet l'entrée pour ce serveur aurait été:

Host domain.com
    HostName domain.com
    User admin
    IdentityFile ~/.ssh/id_domain_com

Juste pour préciser que vous devez vous assurer que le User, Hostet HostNameest correctement défini.

Maintenant, je peux simplement naviguer dans le chemin aller et ensuite go get <package>, par exemple go get mainoù le fichier main/main.gocomprend le package (du dernier exemple ci-dessus) domain.com:username/private-repo.git.


Vous pouvez également importer un package directement avec: go get hostname.com/username/repo.git(l'extension .git est cruciale).
Joachim

y a-t-il un moyen de le faire sans l'extension .gitet pourquoi cela se produit-il?
Cristian Chaparro A.

1
Intéressant, la raison pour laquelle je ne peux pas obtenir le dépôt, sans l' .gitextension c'était que sur ma configuration git locale git config --global url."git@gitlab.myserver.com:".insteadOf "https://gitlab.myserver.com/", mais le sous gitlab.myserver.com- domaine n'a pas la certification ssl, donc j'utilise à la httpplace de https, maintenant
Cristian Chaparro A.

3

Je suis tombé sur .netrcet j'ai trouvé cela pertinent à ce sujet.

Créez un fichier ~/.netrcavec le contenu suivant:

machine github.com
    login <github username>
    password <github password or Personal access tokens >

Terminé!

De plus, pour les dernières versions de GO, vous devrez peut-être l'ajouter aux variables d'environnement GOPRIVATE=github.com (je l'ai ajouté à mon .zshrc)

netrc améliore également la configuration de mon environnement de développement car mon accès github personnel pour HTTPS est maintenant configuré pour être utilisé sur toute la machine (tout comme ma configuration SSH).

Générez des jetons d'accès personnels GitHub: https://github.com/settings/tokens

Si vous souhaitez vous en tenir à l'authentification SSH, masquez la demande d'utiliser ssh avec force

git config --global url."git@github.com:".insteadOf "https://github.com/"

Plus de méthodes pour configurer l'accès git: https://gist.github.com/technoweenie/1072829#gistcomment-2979908

Voir la page de manuel et cette réponse pour son utilisation avec Git sous Windows en particulier


2

Pour moi, les solutions proposées par d'autres donnaient encore l'erreur suivante pendant go get

git@gl.nimi24.com: Autorisation refusée (publickey). fatal: impossible de lire à partir du référentiel distant. Veuillez vous assurer que vous disposez des droits d'accès appropriés et que le référentiel existe.

Ce qu'exigeait cette solution

  1. Comme indiqué par d'autres:

    git config --global url."git@github.com:".insteadOf "https://github.com/"

  2. Suppression de la phrase de passe de ma ./ssh/id_rsaclé qui a été utilisée pour authentifier la connexion au référentiel. Cela peut être fait en entrant un mot de passe vide lorsque vous y êtes invité en réponse à:

    ssh-keygen -p

Pourquoi cela fonctionne

Ce n'est pas une jolie solution de contournement car il est toujours préférable d'avoir une phrase de passe sur votre clé privée, mais cela causait des problèmes quelque part dans OpenSSH.

go getutilise en interne git, qui utilise openssh pour ouvrir la connexion. OpenSSH prend les certificats nécessaires pour l'authentification de .ssh/id_rsa. Lors de l'exécution de commandes git à partir de la ligne de commande, un agent peut se charger d'ouvrir le fichier id_rsa pour vous afin que vous n'ayez pas à spécifier la phrase de passe à chaque fois, mais lorsqu'il est exécuté dans le ventre de go get, cela n'a pas fonctionné dans mon Cas. OpenSSH veut alors vous demander un mot de passe mais comme ce n'est pas possible en raison de la façon dont il a été appelé, il imprime dans son journal de débogage:

read_passphrase: impossible d'ouvrir / dev / tty: aucun périphérique ou adresse de ce type

Et échoue tout simplement. Si vous supprimez la phrase de passe du fichier de clé, OpenSSH accédera à votre clé sans cette invite et cela fonctionnera

Cela peut être dû au fait que Go récupère des modules simultanément et ouvre plusieurs connexions SSH à Github en même temps (comme décrit dans cet article ). Ceci est quelque peu soutenu par le fait que le journal de débogage d'OpenSSH a montré que la connexion initiale au référentiel a réussi, mais l'a réessayé plus tard pour une raison quelconque et cette fois a choisi de demander une phrase de passe.

Cependant, la solution d'utiliser le multiplexage de connexion SSH telle que proposée dans l'article mentionné ne fonctionnait pas pour moi. Pour mémoire, l'auteur a suggéré d'ajouter la configuration de collowing au fichier de configuration ssh pour l'hôte concerné:

  ControlMaster auto
  ControlPersist 3600
  ControlPath ~/.ssh/%r@%h:%p

Mais comme indiqué, pour moi cela n'a pas fonctionné, peut-être que je l'ai mal fait

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.