Раньше у меня было приложение Node в веб-приложении Azure, которое теперь является приложением Go. Проблема в том, что при развертывании я получаю от Куду следующее:
Using cached version of deployment script (command: 'azure -y --no-dot-deployment -r "D:\home\site\repository" -o "D:\home\site\deployments\tools" --node --sitePath "D:\home\site\repository"').
Это, очевидно, позже жалуется на то, что файл server / app.js не найден.
Поэтому я попытался создать сценарий развертывания для своего приложения с azure site deploymentscript --go.
Несмотря на то, что у меня GO15VENDOREXPERIMENT = 1 в настройках приложения, он жаловался на зависимости. Все мои зависимости хранятся в папке / vendor.
Затем я установил эту переменную в файле deploy.cmd, который был сгенерирован командой azure site deploymentscript.
Тем не менее он жалуется, что одной зависимости нет. Обратите внимание, что теперь он ищет в дереве локальных поставщиков, но зависимости есть, я вижу это в репозитории Github, и я также вижу его локально.
У меня есть другие приложения Go, которые прекрасно развернуты с зависимостями поставщиков в Azure, но это приложение, которое раньше было Node, просто не работает вообще.
Я даже попытался прокомментировать получатель зависимостей из deploy.cmd, поскольку все они локальны, этого не требуется. Но даже это не сработало, потому что go build не смог пожаловаться на отсутствие зависимости. Он находится в папке поставщика, а для GO15VENDOREEXPERIMENT установлено значение 1 в файле cmd и в настройках приложения.
Итак, какой у меня здесь вариант?
Как я могу сказать Kudu использовать развертывание Go по умолчанию, возможно, будет работать развертывание из Azure, поскольку в моем другом приложении нет локальных файлов .deployement и deploy.cmd.
Редактировать
Я только что провел тестовое развертывание в совершенно новом веб-приложении Azure, и по умолчанию оно определяется как приложение Node. Я предполагаю, что это из-за наличия package.json в корне, у меня также есть main.go с package main в качестве имени пакета.
Так, может быть, это просто deploy.cmd, созданный azure site deploymentscript, который не является актуальным или что-то в этом роде? (Я обновил свою версию azure-cli просто к сведению, так как сначала у меня не было флага --go).
Просто для полноты, вот результат Kudu при развертывании в только что созданном приложении, с той же ошибкой, что и Node one:
remote: Resolving dependencies
remote: # cd .; git clone https://github.com/org/mypkg D:\local\Temp\8d3397e1e014401\gopath\src\github.com\org\mypkg
remote: Building Go app to produce exe file
remote: Cloning into 'D:\local\Temp\8d3397e1e014401\gopath\src\github.com\org\mypkg'...
remote: fatal: could not read Username for 'https://github.com': Bad file descriptor
remote: package github.com/org/pkg/lib: exit status 128
remote: azureapp\main.go:3:8: cannot find package "github.com/org/pkg/lib" in any of:
remote: D:\local\Temp\8d3397e1e014401\gopath\src\azureapp\vendor\github.com\org\pkg\lib (vendor tree)
remote: Copy files for deployment
remote: D:\Program Files\Go\1.5.3\src\github.com\org\pkg\lib (from $GOROOT)
remote: D:\local\Temp\8d3397e1e014401\gopath\src\github.com\org\pkg\lib (from $GOPATH)
remote: KuduSync.NET from: 'D:\home\site\repository' to: 'D:\home\site\wwwroot'
remote: Could Not Find D:\home\site\repository\azureapp.exe
remote: Copy web.config
remote: web.config already existed. Skip
remote: Finished successfully.
remote: Running post deployment command(s)...
remote: Deployment successful.
Почему он пытается клонировать библиотеку, эта строка здесь [вторая строка], вероятно, является причиной всей проблемы:
remote: # cd .; git clone https://github.com/org/mypkg
Почему, если установлен SET GO15VENDOREXPERIMENT=1, он пытается клонировать зависимость? В другом моем приложении Go этого не происходит.
