0

初めての Laravel Forge サーバーをセットアップしているところです。すべてが順調に進んでいるように見えます。コードは Git リポジトリから取得され、Web サイトをオンラインで見ることができます。何らかの理由で、データベースの移行が機能していません。

Forge で「Deploy」コマンドを実行すると、Forge イベント ログに次のエラーが表示されます。

From repohost:myusername/myrepo
 * branch            master     -> FETCH_HEAD
Already up-to-date.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files
Generating optimized class loader
Compiling common classes
Compiling views
Migration table created successfully.



  [RuntimeException]  
  Aborted             



migrate [--bench[="..."]] [--database[="..."]] [--force] [--path[="..."]] [--package[="..."]] [--pretend] [--seed]

migrateターミナルから(and ) コマンドを実行しようとしましたmigrate:refreshが、ハングするだけで、最終的には CTRL-C を使用する必要があります (を使用している場合でも--verbose)。後でデータベースを調べると、移行テーブルのみが作成されており、空です。

また、開発環境 (Homestead) ですべての移行を再実行してみましたが、正常に動作します。

誰がこれを引き起こしているのか知っていますか?

4

1 に答える 1

1

ここでさまざまな問題にぶつかっています。おそらく、誰かがあなたを助ける前に、さらにデバッグを行う必要があります。また、forge は「Laravel ホスティングに最適化されていますよね?」-- 私は彼らのサポートを打ってみます。結局のところ、それはあなたが支払っているものです。

まず、スローされた例外: [RuntimeException]Aborted.

標準の Laravel インストールでは、"Aborted" メッセージをスローする唯一の例外は、artisan が基づいている Symfony コンソール コンポーネントからのものです。具体的には、次のファイル/クラス定義内のaskおよびメソッドでdoAsk

vendor/symfony/console/Symfony/Component/Console/Helper/DialogHelper.php
vendor/symfony/console/Symfony/Component/Console/Helper/QuestionHelper.php

具体的にはartisan、コマンドからの応答の読み取りに問題がある場合、Symfony コンポーネントはこれらの例外をスローします。

#File:     vendor/symfony/console/Symfony/Component/Console/Helper/DialogHelper.php

    if (null === $autocomplete || !$this->hasSttyAvailable()) {
        $ret = fgets($inputStream, 4096);
        if (false === $ret) {
            throw new \RuntimeException('Aborted');
        }
        $ret = trim($ret);
    }

これらは追跡するのが非常に難しいバグであり、スクリプトによって返される入力が多すぎる (巨大なスタック トレースなど)、PHP が処理できない無効な入力、使用している端末アプリケーションの問題などに関係している可能性があります。サーバーに接続する方法、またはサーバー自体が構成された方法。

つまり、例外はおそらく実際のエラーとは何の関係もありません。

動作に基づいて、移行が端末で処理できないスタック トレースをスローするか、データベースのデッドロックを作成するように思えます。面倒だけどやりたい

  1. 非本番サーバーで問題を切り分けて再現する

  2. データベースを削除します

  3. 移行をサブ フォルダーに移動する

  4. 各移行を 1 つずつ追加し、実行してみます

最終的に、問題の原因となっている移行が見つかり、そこからデバッグできます。

于 2015-01-29T18:43:38.570 に答える