Google Cloud Builder - как вызвать конфигурацию сборки в подкаталоге? - PullRequest
0 голосов
/ 09 октября 2018

Я пытаюсь установить триггер сборки Google Cloud Builder для автоматического построения и развертывания моего ASP .NET Core в Google AppEngine.

Использование текущего cloudbuild.yaml:

   steps:
   - name: 'gcr.io/cloud-builders/dotnet'
     args: [ 'publish', '-c', 'Release' ]

   - name: 'gcr.io/cloud-builders/gcloud'
     args: ['app','deploy','./bin/Release/netcoreapp2.1/publish/app.yaml']

Я протестировал локальную сборку, используя инструмент cloud-build-local.

Эти два подхода работали локально:

  1. Из подкаталог приложения : cloud-build-local --config=cloudbuild.yaml --dryrun=false .
  2. Из корня хранилища : cloud-build-local --config=clearbooks-rest-aspnetcore/cloudbuild.yaml --dryrun=false clearbooks-rest-aspnetcore

Кажется, что определение триггера сборки частично поддерживает файлы конфигурации изподкаталог корня хранилища (подход № 2), однако, похоже, предполагается, что код всегда находится в корне хранилища.

Как настроить Cloud Builder для запуска сборки в подкаталоге хранилища?

1 Ответ

0 голосов
/ 11 октября 2018

Решение заключается в обновлении cloudbuild.yaml:

  1. Добавьте параметр dir: на этапе сборки
  2. Укажите правильное app.yaml расположение для этапа развертывания

Вот рабочий cloudbuild.yaml:

steps:
- name: 'gcr.io/cloud-builders/dotnet'
  args: [ 'publish', '-c', 'Release' ]
  dir: 'clearbooks-rest-aspnetcore'

- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app','deploy','clearbooks-rest-aspnetcore/bin/Release/netcoreapp2.1/publish/app.yaml']

При локальном тестировании запускайте cloud-build-local в корне хранилища, а не в подкаталоге приложения:

cloud-build-local --config=clearbooks-rest-aspnetcore/cloudbuild.yaml --dryrun=false .

Отражает способ работы Cloud Build:

  1. Путь к исправлению cloudbuild.yaml
  2. Текущий каталог для источника
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...