Мы оцениваем переход на monorepo, размещая наши приложения на Heroku.Наше дерево исходных текстов выглядит следующим образом:
.
├── Gemfile
├── Gemfile.lock
├── backend
│ ├── logger
│ │ ├── Gemfile
│ │ ├── Gemfile.lock
│ │ └── Procfile
│ └── legacy
│ │ ├── Gemfile
│ │ ├── Gemfile.lock
│ │ └── Procfile
└── shared
├── gems
│ └── protos
└── protos
Мы нашли несколько пакетов сборки, относящихся к монорепосам, а именно heroku-buildpack-monorepo и heroku-buildpack-multi-procfile .
В первом случае buildpack перезаписывает корень развертывания с помощью подкаталога, содержащего приложение.Например, APP_BASE имеет значение backend/logger.Это было бы хорошо, но мы планируем использовать совместное использование драгоценных камней между различными приложениями, и перезапись дерева исключает это: backend/logger перезапишет ., удалив доступ к shared/gems.
Во втором случаеProcfiles требуется cd до нужного каталога перед запуском приложения.Наш Procfile выглядит следующим образом:
worker: cd backend/logger && bundle exec bin/logger
Это был бы наш предпочтительный путь вперед.
Проблема в том, что стандартный пакет сборки heroku / ruby не знает cd в каталоге приложениядо строительства.Сообщение об ошибке, которое я вижу при развертывании:
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Multi-procfile app detected
remote: Copied backend/logger/Procfile as Procfile successfully
remote: -----> Ruby app detected
remote: -----> Compiling Ruby
remote: -----> Using Ruby version: ruby-2.5.3
remote: -----> Installing dependencies using bundler 1.15.2
remote: Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
remote: Warning: the running version of Bundler (1.15.2) is older than the version that created the lockfile (1.17.2). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
remote: Fetching gem metadata from https://rubygems.org/..............
remote: Fetching version metadata from https://rubygems.org/.
remote: Fetching rake 12.3.2
...
remote: Installing rubocop 0.61.1
remote: Bundle complete! 4 Gemfile dependencies, 14 gems now installed.
remote: Gems in the groups development and test were not installed.
remote: Bundled gems are installed into ./vendor/bundle.
remote: Bundle completed (4.54s)
remote: Cleaning up the bundler cache.
remote: -----> Detecting rake tasks
remote:
remote:
remote: -----> Discovering process types
remote: Procfile declares types -> release, worker
remote: Default types for buildpack -> console, rake
remote:
remote: -----> Compressing...
remote: Done: 34.4M
remote: -----> Launching...
remote: ! Release command declared: this new release will not be available until the command succeeds.
remote: Released v8
remote: https://stb-logger-staging.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy... done.
remote: Running release command...
remote:
remote: bundler: command not found: sequel
remote: Install missing gem executables with `bundle install`
Установленные гемы - это те, которые объявлены в Gemfile рута.Задача release была бы успешной, если бы в buildpack было значение cd'd для backend/logger и оттуда bundle install.
Вопрос: какие у нас варианты?Я, вероятно, могу создать / расширить пакет сборки, который будет копировать / перемещать папку shared / gems в место, которое все еще доступно на этапах компиляции и развертывания.Есть ли сборочный пакет, о котором я не знаю, который поддерживает наш вариант использования?
PS: я исследовал https://github.com/Pagedraw/heroku-buildpack-select-subdir,, но он не прошел 5-минутный тест.Первое развертывание ничего не развернуло.