私は 'composer update' を使い、いくつかのパッケージを更新しました。アップデートの間、ウェブサイトはまだ機能しています。しかし、 'The compiled services file has been removed' と表示された後、ウェブサイトはロードされず、代わりにこう表示されます。
Exception in ProviderRepository.php line 190:
The bootstrap/cache directory must be present and writable.
一番不思議なのは、 'composer update' を再度実行すると、コンパイルされたサービスファイルが削除されるまで、ウェブサイトが再び動き出し、その時点で再び同じエラーを投げます。このエラーが表示されたときに行うべき通常のこと(chown -R everything to the right user/group and chmod all the files and folders respectively 664 and 775)はすでに試しています。
このエラーは '正しくないようなので、もうどうしたらいいのかわかりません。
Short version:AWS eb cli__ のようなものを使ってアップロードする場合 bootstrap/cache フォルダ (その中身についてではなく) がデプロイされているかどうかを確認する。
私の回答の背景にはいくつかの理由があります。
私は、Amazon Web Services' Elastic Beanstalkを使用して、Laravelプロジェクトをホストしています。私はLaravelを使い始めたばかりなので、その機能についてはあまり知りません。また、このような場合、「Skype」を利用すると便利です。
その日のうちに、私は自分が
php artisan config:cache
を使用して設定をキャッシュし、高速化を図りました。そして、composer.json'の "post-install-cmd" と "post-update-cmd" 節に同じものを追加しました。
また、.ebignore ファイルに /bootstrap/cache の内容をアップロードしないように記述しました(その内容は環境依存なので a.k.a 私の localhost 設定は本番サーバでは意味がない)。
そして facepalm これが bootstrap/cache フォルダのアップロードを止めることになるとは気づきませんでした(git のように eb cli は空のフォルダを無視するのです)。
So, I started to deploy at night The deployments meant to crash.これは、私が夜にデプロイを始めたとき、デプロイはクラッシュすることになっていた。
ということで、今は_bootstrap/cache_に空のプレースホルダー(例えば) .gitkeep ファイルを置くだけにしています。そして、デプロイは再び動作しています :)
(問題があまりに単純だったので、EBSのEC2インスタンスをsshで掘って、何時間か甘い眠りについた後に原因に気付きました ~.~ )
プロジェクトフォルダで実行できます。
sudo chmod -R 777 bootstrap/cache
走るより。
composer update
走るより。
cache:clear