This is a Heroku Buildpack for Ruby, Rack, and Rails apps which are not in top-level of the repository. It relies on unchanged Heroku Buildpack for Ruby under the hood.
Let's say you have following repository structure:
.
├── ecommerce
│ ├── crm
│ ├── ordering
│ ├── payments
│ ├── pricing
│ └── product_catalog
└── rails_application
├── Gemfile
├── Gemfile.lock
├── Rakefile
├── app
├── bin
├── config
├── config.ru
├── db
├── lib
├── log
├── public
├── test
├── tmp
└── vendor
There's a Rails application under rails_application/
. There's also ecommerce/
— a bunch of components this app relies on, but not the other way round.
Now, you want to promote rails_application/
to Heroku dyno:
-
pushing subdirectory via
git subtree push --prefix rails_application heroku master
would cut you off from the component dependencies -
same issue with other popular monorepo buildpacks, which only promote chosen subdirectory to root
-
packaging and distributing components as gems introduces burden when introducing changes and releasing them, quickly defeating benefits of the monorepo
-
collapsing everything into a single, top-level package/bundle just for the deployment simply makes production debugging much worse
Luckily with this buildpack, there's no need for compromises!
Tell it where your application lives via APP_DIR
variable and it will do the rest:
-
preserve exactly the same directory structure on Heroky dyno
-
execute stock, up-to-date Ruby buildpack at the application root
-
ensure
$PATH
and$GEM_PATH
are aware of given application root -
copy
Procfile
from application root to top-level directory, making necessary path changes so that Heroku recognizes avaiable process types and can instantly runweb
Set it as your only buildpack first:
heroku buildpacks:set https://github.com/arkency/heroku-buildpack-ruby-monorepo
Let it know, where the application is:
heroku config:set APP_DIR=rails_application
- hardcoded Ruby buildpack, there was no need to make it generic so far
After all it is not a very sophisticated Heroku buildpack.