Fix cache rebuild

[badri]

Summary

Resolve #107

Use Cases

Certain frameworks, most notably Drupal, place modules and themes downloaded from composer install in directories other than the vendor directory. During a cache restore phase for the composer install buildpack, this will get erased because of which the final image won't serve the web application.

This is fixed by running composer install even if the cached layer is being reused. This places the already downloaded and cached dependencies in the appropriate non-vendor directories. This can be toggled by setting the BP_RUN_COMPOSER_INSTALL env var to 1.

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: badri / name: Lakshminp (69b8bf5, 5ac6019, 8715f8e, b618a1b)

[badri]

Didn't add labels.

[arjun024]

Thanks for the PR @badri
I'm not familiar with Drupal at all, but instead of ignoring caching to run "composer install" again, can we cache the web directory as well, and (I'm just think out aloud here) do you think we can make use of composer.json/installer-paths to figure out if web has to be restored as well?

@sophiewigmore @effulgentsia - thoughts?

[badri]

@arjun024 the web directory will contain custom business logic in addition to housing the downloaded composer modules. So, caching it and restoring will override the custom logic. Instead, what we can do is, re-run composer install in that phase so that composer will place the already downloaded modules from that layer into the appropriate locations under web.
This is only needed for Drupal and other PHP frameworks which follow this practice. Hence controlling it through a build time env var.
This won't re-download the files or nullify the benefits of caching the composer layer in any way.

Of course, I'm eager to hear opinions of others :)

I've been using paketo buildpacks since Drupal 8 and I had to resort to creating my own buildpacks to circumvent this problem where I was essentially doing the same thing.

[sophiewigmore]

the web directory will contain custom business logic in addition to housing the downloaded composer modules. So, caching it and restoring will override the custom logic

@badri can you explain a bit more about what you mean by this? What type of errors do you encounter when you do this?
I'm also interested if you ever looked into @effulgentsia's idea of checking if there's a way to keep track of directories created by composer install?

Overall, if re-running composer install will still be able to leverage the cached dependencies, then I'm open to this approach for sure. I'd ideally like to find a way for us to cache the other directories that composer installs if we can safely find a way to do that

P.S. thanks for the contribution!

[sophiewigmore]

If we do end up going with the environment variable, we usually use booleans for this type of environment variable, so I'd want to see this changed to true/false. I'd also want to see this env. var documented in the README with the rest of the configurations.

Let's not make these changes until we (you and @paketo-buildpacks/php-maintainers) are in agreement about how to do this