Aws-cli: コードデプロイ-未処理の例外-ZIPは1980年より前のタイムスタンプをサポートしていません

同じエラー：
aws cloudformation package ...

Uploading to a5902e46b3516ee3f44caf6251079b5f  1846 / 1846.0  (100.00%)
Unable to upload artifact ./../async-handlers/donation-created-handler referenced by CodeUri parameter of DonationCreatedHandlerFunction resource.
ZIP does not support timestamps before 1980

1.11.79 （しばらく前に機能していた）にダウングレードした後でも、同じエラーが発生します。

完全なビルドログ

タイムスタンプが無効なファイルがあるようです。 これはより大きな問題を示している可能性があるため、修正することをお勧めします。 Python自体でエラーが発生するため、CLIのバージョンを変更してもこれには影響しません。

今日、create_application_revisionコマンドの実行中に、CircleCIとまったく同じエラーメッセージが表示されます。

`` `create_application_revision /tmp/codedeploy_applications.json /tmp/codedeploy_revisions.json

create_application_revisionが読み込まれました：{"applications"：[{"region"： "us-west-2"、 "application_root"： "/"、 "revision_location"：{"s3Location"：{"bucket"： ""、"鍵"：""}、" RevisionType "：" S3 "}、" deployment_group "：" staging "、" application_name "：""}]}
バンドル/ home / ubuntu /から
未処理の例外
ZIPは1980年より前のタイムスタンプをサポートしていません

（（create_application_revision "/tmp/codedeploy_applications.json" "/tmp/codedeploy_revisions.json"））が終了コード1を返しました
`` `

これに関するCircleCIのサポートフォーラムにはバグレポートもあります。

@JordonPhillips迅速なフィードバックに感謝します。 CircleCiの問題について誰かが私たちに戻ってくるかどうかを確認するのを待ちます。 @ arsenio-コードデプロイを介して手動でデプロイしたことに注意してください。これにより、短期的に問題が解決しました。

だから私にとってuglify-jsは1969年に作成されたファイルを手に入れました。
回避策として、これを追加しました。

find ./dist/ -type f -exec touch -t 201601011200 '{}' \;

これは私たちにも起こっています。 日曜日以降、Shippableビルドサーバーで、ローカルでrm -rf node_modules

eb deploy
Creating application version archive "app-bce1-170606_163952".
ERROR: ValueError :: ZIP does not support timestamps before 1980

これはnodejsアプリ、EB CLI 3.9.0（Python 2.7.1）です。

更新： @mgibasが言うように、これはuglify-jsが

@mgibasと保存： ugllify-jsライブラリ内の特定の（すべてではない）ファイルには、1969年のタイムスタンプがあります。 これらのファイルに触れると、この厄介なハードルを乗り越えることができます。

実際、私にはWebpackのNPMパッケージの問題のようです。 投稿された問題https://github.com/webpack/webpack/issues/5022

ええ、uglifyはかなり一般的な依存関係のようです:)

https://github.com/mishoo/UglifyJS2/issues/2054

@sumothecatそれはWebpackの問題ではありません。 これは、webpackが使用するUglifyJSの問題です。 コミュニティは、 @ mgibasによってリンクされているように、正しい場所に指を

@ eric-tucker Uglifyは使用しませんが、Webpackには暗黙の依存関係があります。 Webpackでこの問題を解決しました。今後、ヤーンロックファイルを使用する予定です。

ここでも同じです、何か考えはありますか？

私のアプリケーションでは、 jestとwebpack両方が、破損したバージョンのuglify-jsをもたらしていました。

すでにnpm-shrinkwrap使用しているので、 npm-shrinkwrap.jsonファイルに次の行を追加しました-

"uglify-js": {
      "version": "2.8.27",
      "from": "uglify-js@=2.8.27",
      "resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.27.tgz"
    },

これにより、この問題を一時的に回避できます。

mgibasの回答を見ると、yarnインストールまたはnpmインストール後に今のところうまくいった一時的な解決策があります。

find node_modules/uglify-js -print -exec touch {} \;

package.jsonファイルに追加するより堅牢なハック：

{
  "scripts": {
    "install": "find ./node_modules/* -mtime +10950 -exec touch {} \\;"
  }
}

これにより、各npm installコマンドの後で30年以上経過した各ファイルがtouchなります。

まだこの問題を抱えている人はいますか？
mtimeを破壊するNPMのバグはその後修正されました。
そして、UglifyJSの新しいバージョンが公開されました。

また、 aws-sdk依存関係であるieee754モジュールの問題のようです。 この問題が報告されています： //github.com/feross/ieee754/issues/17

同じ問題が発生しました。今回は@slack / clientnpmが原因です。

一部のタイムスタンプが壊れることには間違いなく問題がありますが、このCLIツールがなぜ気にする必要があるのか​​わかりません。 この問題の原因となる無効なタイムスタンプの理由は何ですか？ この問題を完全に回避するためにサポートできる方法はありますか？

私も同じ問題を抱えていました。 私はすべてを試しましたが、ラップトップを再起動するだけでうまくいきました。

同じ問題であり、このライブラリの最新バージョンを使用しているため、 uglify-js問題ではありません。

上で示唆したように私はちょうど走った
find ./node_modules/* -mtime +10950 -exec touch {} \;
プロジェクトのルートディレクトリからvscodeターミナルで、それを修正しました

eb deployは私にくれた

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
問題を解決しました。

これは、依存関係が異なる複数のプロジェクトで繰り返し発生する問題です。

私はまだこの問題に遭遇します。

開発依存関係としてnyc（istanbul）を追加したときにもこの問題が発生しましたが、この問題の根本原因であるuglify-jsが追加されたようです。

私のPoVからは、Macのyarnに関連しているようです。
Macでnpmを使用する場合は、すべて問題ありません。
Ubuntuでyarnを使用する場合は、すべて問題ありません。
uglify-jsや他の多くの依存関係があっても。
AWS SAMのhello-world（https://github.com/awslabs/aws-sam-cli/tree/develop#package-and-deploy-to-lambda）をパッケージ化することでデモできます。
それ以外の場合、 https： //github.com/aws/aws-cli/issues/2639#issuecomment -391255985は完全にトリックを実行し

すべてのdevDependenciesパッケージをスキップするyarn --productionを使用します。これは、この問題の解決に役立ちます。

残念ながら、私はこの問題の原因となる本番環境のいくつかのパッケージに依存しているため、 yarn --productionは役に立ちません。

それは、言ったyarn --productionでタイムスタンプを固定する前にnode_modules/大幅ビルド時間を短縮ありません。

Windowsコマンドとは何ですか

find ./node_modules/* -mtime +10950 -exec touch {} \;

これを自分のコンピューターで実行できません

これは、 zipfile pythonライブラリのstrict_timestamps引数を使用して修正できたようです。