Currently we’re setting up a workflow with one job being the installing of composer dependencies. It’s a pretty basic job which restores the vendor folder from cache, installs dependencies (only if restoring from cache fails) and then saves again to cache. I use the checksum of both composer.json and composer.lock as caching key. So far so good.
However when running composer with the --optimized-autoloader flag it seems to hardcode paths in the autoload files which are stored in vendor/composer. We’re now running into the issue where we removed a PHP class but it still being referenced in the autoload files restored from the cache (because the composer.json/lock didn’t change it obviously didn’t reinstall dependencies).
As it is not possible to create checksum keys based on files which are not in my VCS repository (i.e. the autoload files), is there some way to use CircleCI’s caching mechanism for composer? Reverting to having to install composer dependencies in every job would kind of suck
The removed class was not a dependency, it was a redundant controller no longer used by the app. If I understand the --optimize-autoloader flag of composer correctly, it creates class-map rules for classes loaded via psr0/psr4 rules thus it will have hardcoded references in the vendor/composer/autoload_*.php files.
Basically I would need to regenerate the autoload files on each build (which is fine) but I don’t know a good way of determining whether any new classes were added or removed (so I can define a proper cache-key).
Always install dependencies (along with generating autoload files)
I now restore/cache the composer cache which greatly speeds up installing of dependencies
Use branch + revision as cache key so the vendor folder always gets newly cached, this allows for easy sharing of the vendor folder between jobs in the workflow
These steps solved my issue while the job takes only 20 seconds longer (I was expecting this to be way worse) so overall I’m happy
