php artisan config:cache
を実行すると、Laravel構成ファイルにデフォルトでstorage_path()
の呼び出しがあるため、結果のキャッシュに絶対パスがあることに気付きました。
ドキュメントを読みました:
通常、本番デプロイメントルーチンの一部としてphp artisan config:cacheコマンドを実行する必要があります。
ドキュメントには、自動CIビルドエージェントではなくサーバーでコマンドを実行する必要があるとは記載されていません。 ただし、CIビルドエージェントからリモートで実行するために、サーバー上のphp artisan config:cache
コマンドに誰もがアクセスできるわけではありません。
サーバーでコマンドを実行するための要件を反映するように、ドキュメントを更新する必要があると思います。
ただし、相対パスを使用して構成キャッシュを生成する方法を実装することをお勧めします。
現在、この問題の回避策を追加し、職人のコマンドを実行するPHPコントローラーを作成して、デプロイ中に呼び出すことができます。 しかし、問題は、サーバー展開がGitプッシュを介して機能するように設定されており、数分後にWebサイトがリポジトリ内の現在のバージョンと同期されることです。 CIデプロイスクリプト内に座って、 php artisan config:cache
を実行するカスタムコントローラーへのURLを呼び出すことができるようになるまで、不明な時間を待つのは良い考えではないと思います。
それで、質問に戻ります-アプリのルートに相対的な構成ファイルのパスを作成し、相対パスで機能するキャッシュされた構成を生成する方法は?
デプロイ前ではなく、サーバー上でcomposerと最適化コマンドを実行する必要があります。
前述のLaravelのドキュメントの引用では、「デプロイルーチン」は、デプロイしようとしているフォルダーではなく、サーバーでcacheコマンドを実行する必要があることを明示的に意味するものではありません。 したがって、私はこの文を拡張する価値があると思います。そうすれば、人々は(私がしたように)誤った仮定をしません。
とにかく、設定ファイルでstorage_path()の代わりに相対パスを使用できないのは残念です。 これにより、自動CIデプロイメントがはるかに簡単になります。
はい、そのため、ドキュメントには「ビルドルーチン」ではなく「デプロイメントルーチン」と記載されています...
最も参考になるコメント
前述のLaravelのドキュメントの引用では、「デプロイルーチン」は、デプロイしようとしているフォルダーではなく、サーバーでcacheコマンドを実行する必要があることを明示的に意味するものではありません。 したがって、私はこの文を拡張する価値があると思います。そうすれば、人々は(私がしたように)誤った仮定をしません。
とにかく、設定ファイルでstorage_path()の代わりに相対パスを使用できないのは残念です。 これにより、自動CIデプロイメントがはるかに簡単になります。