Блог

У меня есть проект golang, и я поместил код где-то на сервере git. Весь мой код теперь находится в $GOPATH/mygitserver/folder/.

Все является товаром до тех пор, пока gitserver не изменит URL, поэтому мне нужно заменить весь импорт на новый URL gitserver. Итак, я не хочу, чтобы это повторилось в будущем, и хочу изменить способ, которым это работает.

Итак, вместо того, чтобы отправлять пакет только на мой сервер git, теперь я планирую загрузить все рабочее пространство в git (исключая внешнюю библиотеку). Итак, у меня будет пакет непосредственно в папку src (пример: src / mypackage). Итак, когда я изменяю URL gitserver, все по-прежнему будет работать.

Вопрос в том, хорошо ли это делать (загружать рабочее пространство в git)? Или у нас есть другой вариант?

А также возникает другая проблема, которой раньше не было. Итак, после того, как я клонирую свое рабочее пространство, я должен вызвать «go get» для всей моей библиотеки, используемой проектом. (Раньше этого не случалось, потому что, когда я вызываю go get mygitserver / package, Golang автоматически загружает зависимость). Есть ли какой-либо способ сделать так, чтобы все зависимости загружались моей всего одной командой?

Если вы ожидаете, что ваш сервер будет часто перемещаться, одним из возможных решений является использование пути импорта тщеславия.

Пути импорта Vanity позволяют сохранять ваш код по пути импорта в вашем домене, который перенаправляет вас в местоположение, где хранится код. Например, если вы размещаете свой код на Bitbucket, но беспокоитесь, что в будущем можете переехать, и вы являетесь владельцем домена example.net , вы могли бы разместить свой код так, чтобы импортировать его с помощью import "example.net/myproject" , а за кулисами go get инструмент извлек бы его из Bitbucket. Для этого вы должны предоставить документ в нужном домене, который содержит пользовательский мета-тег вида:

 <meta name="go-import" content="import-prefix vcs repo-root">
  

Так, например, обслуживание следующего HTML-файла по адресу example.net/myproject приведет к перенаправлению go get на клонирование предоставленного URL Bitbucket (он также, конечно, может указывать на любую другую службу Git, включая вашу собственную):

 <meta name="go-import" content="example.net/myproject git https://bitbucket.org/myname/myproject.git">
  

Чтобы настроить Nginx для обслуживания этих перенаправлений, можно использовать конфигурацию, подобную следующей (разумеется, заменив myPackage и URL-адреса на название вашего проекта и URL-адреса):

 location ~ /myPackage/[a-z][a-z0-9]* {
    if ($args = "go-get=1") {
        add_header Content-Type text/html;
        return 200 '<meta name="go-import" content="$host/myPackage git https://bitbucket.org/myName/myPackage.git">';
    }
    rewrite ^ https://mygithosting.example.org/myName/myPackage? permanent;
}
location ~ /myPackage$ {
    if ($args = "go-get=1") {
        add_header Content-Type text/html;
        return 200 '<meta name="go-import" content="$host/myPackage git https://mygithosting.example.org/myName/myPackage.git">';
    }
    rewrite ^ https://mygithosting.example.org/myName/myPackage? permanent;
}
  

Теперь в любой момент, когда вы перемещаете свой Git-сервер, вы можете просто изменить URL в мета-теге.

Если вы беспокоитесь о том, что некоторые пользователи импортируют напрямую с вашего сервера Git, а другие используют путь импорта vanity, вы также можете задать этот путь в качестве канонического пути импорта пакетов. Канонические пути импорта указаны в виде специальных комментариев в package строке в одном файле программы Go (не имеет значения, в каком именно). Они выглядят следующим образом:

 import mypackage // import "example.com/mypackage"
  

Теперь, если приведенный выше код на самом деле размещен где-то еще, и кто-то попытается импортировать его напрямую, go get будет жаловаться:

$ go получить mygithosting.example.org/myName/myPackage пакет mygithosting.example.org/myName/myPackage: код в каталоге /go/mygithosting.example.org/myName/myPackage ожидает импорта «example.com/mypackage «