cloudfoundry / php-buildpack

A Cloud Foundry Buildpack for PHP.
Apache License 2.0
142 stars 348 forks source link

Laravel view cache #306

Closed bluemmb closed 5 years ago

bluemmb commented 5 years ago

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

What version of the buildpack you are using?

If you were attempting to accomplish a task, what was it you were attempting to do?

"scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi",
            "@php artisan config:cache",
            "@php artisan route:cache",
            "@php artisan view:cache"
        ],
}

What did you expect to happen?

What was the actual behavior?

Runs the scripts when is inside 'tmp' folder, so the generated paths for cache files are not correct.

As I have understood everything get run in tmp folder and then they get copied to home folder.

Actually I don't know where should I put cache scripts so they get run by the time files are copied to 'home' folder.

cf-gitbot commented 5 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/165953931

The labels on this github issue will be updated when the story is started.

dmikusa commented 5 years ago

Runs the scripts when is inside 'tmp' folder, so the generated paths for cache files are not correct. As I have understood everything get run in tmp folder and then they get copied to home folder.

I think what you're seeing is a problem with the file paths during staging vs runtime.

This is simplified a bit, but the buildpack runs during staging, it's in a unique container, and most of its work happens under the /tmp directory. Any files that need to live beyond staging must be copied into the droplet (a special folder, accessible to the buildpack during staging).

When the application runs, the droplet is extracted into a new container for each instance of the app. It is extracted into /home/vcap/app.

As you can see the paths are different, so anything that runs during staging and is saving absolute paths must write /home/vcap/app as the absolute path or the path will not be correct when the app is actually running (since the /tmp/... paths are gone by the time the app runs).

Actually I don't know where should I put cache scripts so they get run by the time files are copied to 'home' folder.

The easiest way to work around this is to not run the process during staging and instead run it right before the app starts. This works great for anything that is fairly lightweight and executes quickly. This is because the task that runs prior to the app starting will block the app from starting & the app has a finite amount of time to start before it fails (usually 60 - 180s).

You can make it run before your app starts by adding a .profile script to the root of your app & putting the command to execute in this script (it's just a bash script).

The other option would be to add a symlink for /home/vcap/app in the staging container and point it to the files under /tmp/.... Then you could have your script run and it would look like it's running under /home/vcap/app in the staging container, and hopefully, it would then be able to generate paths for runtime correctly.

If neither of these options work, you could generate the cache during staging and look at doing a rewrite of the paths in the cache right before your app starts at runtime. Rewriting the paths would be fast, so not a problem to run before your app starts. It would likely be complicated though.

The buildpack has some basic capabilities to do this through the bin/rewrite script which runs to convert config files generated by the buildpack. It basically rewrites anything like @{BLAH} with an the value of an env variable called $BLAH.

The other option would be something like sed which could go search and replace strings in files for you.

Hope that helps!

bluemmb commented 5 years ago

Thanks for perfect explanation.

I used .profile and it works as you said. Thanks again.