S3 デプロイ手順を Grunt ツールチェーンに統合して、新しく構築されたファイルを AWS にアップロードしようとしています。ただし、ステップは常にサイレントに失敗し (成功したと主張しますが、何もしません)、結果をデバッグしているときに、途中でハングアップしているいくつかの異なるポイントを見つけました。grunt コマンドを処理するパッケージとして grunt-s3 を使用しています。これは、Amazon の S3 API をラップする knox パッケージを呼び出します。
物事がバラバラになっている場所は次のとおりです。
1) knox が fs パッケージを使用して、fs.stat(file, callback) 経由でアップロードしようとしているファイルのサイズを取得しようとするポイントがあります。私が知る限り、プロセスは、fs.stat 呼び出しと呼び出されるコールバックの間の node.js レイヤーの下のどこかで停止します。ブレークポイントと「デバッガー」ステートメントをコールバックロジックのいたるところに設定しましたが、ノードインスペクターも IntelliJ デバッガーも fs.stat() が呼び出された後にプロセスをキャッチできないようです。
2) knox プラグインをハックして fs.stat 呼び出しを fs.statSync() に変更すると、プロセスは正常に進みます。ただし、プロセスの後半で、knox が S3 で予期される PUT URL を設定してファイルをアップロードし、stream.pipe() を呼び出してファイルをアップロードすることがわかります。stream.pipe() 呼び出しの結果として何も起こらないように見えます。自分のコンピューターと AWS の間でアップロードが行われていることを示す WireShark でのアクティビティが見られません。ただし、コマンド ライン ツール s3cmd を使用してアップロードすると、ファイルは正常にアップロードされます。
このステップでうなり声を捨てて、s3cmd を直接呼び出す準備が整いましたが、できればうなり声でやりたいと思っています。これらの 2 つのステップで何が起こっているのかについて、何か提案はありますか?
ありがとう！