CHH
Caching the composer dependencies between deployments
When I started deploying my project on heroku, most of the compilation time was the composer install to download all vendors. But most of my deployments were using the same vendors than the previous one (you generally don't change them on each deployment, and you often change only some of them when you do a change).
so I implemented caching of the composer vendors between deployments (inspired by the way heroku does it in its Ruby buildpack for bundler dependencies).
The result is https://github.com/Incenteev/heroku-buildpack-sdz/blob/prod/bin/compile#L171-206
It could be a good idea to implement it in this buildpack too
I dunno if you tried my build pack, but deploys are already pretty fast because Composer's standard caching is already active. It's currently not that easy to implement it, because PHP and NGINX binaries are also at vendor/ and we don't want to cache them with the Composer dependencies.
@CHH Putting PHP itself in vendor/php is a bad idea. I can conflict with some composer packages. There is 2 packages on Packagist using php as vendor name in the package name: https://packagist.org/packages/php/
and nothing guarantees that the other tools you put in vendor (nginx, libicu and libmcrypt) will not conflict with composer either
I also already thought long about this, I oriented myself on the Node build pack, but couldn't come up with any good idea yet. @stof Do you have any idea for a directory to put this stuff in?
Well, the way @Swop choose when writing the his buildpacks (the old one being the base for the buildpack I use) was to move the app in a subfolder. But the drawback is that it moves the application code.
A better idea could be to use a separate folder sibling to vendor. what about platform (or heroku_platform to limit the risk of conflicts with the app) ? Most projects don't have tons of folders in the root, so it should be possible to find a name which does not have too much risk of conflicts.
By the time, I decided to put the vendors (i.e. software dependencies like PHP, Ngnix, Node..., not composer ones) in the /app folder (/ as the Linux root folder, not the root of the building dir).
As @stof describe it before, the application code is moved to a /app/www dir. I think that's not the worst choice because it prevents the collision with the app code because no extra files are added into it (except for the composer dependencies, but the vendor dir is conventional).
I thinks that if the code doesn't live in the /app folder isn't a real issue here and there are no rules about that point (even the official heroku's PHP buildpack puts the app code in a /app/www folder, and install PHP in /app/php : https://github.com/heroku/heroku-buildpack-php/blob/master/bin/compile).
The real deal about folder naming rules lives in the Sf2 cache compilation & warmup phase. The most common way of executing this step is to do it in the slug compilation time. But the warmup phase store absolute folder names into the PHP cache files and this path are wrong (the slug is compiled in a temp folder).
But for the running time, this folder architecture could be used :
/
└── app
├── bin
│ ├── nginx
│ └── php
└── www
├── app
├── src
└── vendor
(and thereby the previous architecture could lets you decide to use Heroku caching dir for the bin folder only, or the composer vendors, or both).
For reference, the official PHP buildpack puts them in .heroku.
However, changing this would be a pain: it would require recompiling all PHP versions and all libs and extensions for the new location, and this would create issues for people using the master branch until the release of the new location, or for people using tags, unless we use a separate folder in the bucket for the packages after the move