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 (الذي كان يعمل منذ بعض الوقت) يعطي نفس الخطأ.

سجل البناء الكامل

يبدو أن لديك بعض الملفات ذات الطوابع الزمنية غير الصالحة. قد يكون هذا مؤشرا على مشكلة أكبر ، لذلك أوصي بإصلاحها. لن يؤثر تغيير نسختك من CLI على هذا لأن الخطأ يظهر في لغة بيثون نفسها.

ألاحظ نفس رسالة الخطأ بالضبط مع CircleCI اليوم ، أثناء الأمر create_application_revision:

`` 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": ""،"مفتاح":""} ،" نوع المراجعة ":" S3 "} ،" مجموعة النشر ":" التدريج "،" اسم التطبيق ":""}]}
التجميعمن / المنزل / 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 '{}' \;

هذا يحدث لنا أيضًا. منذ يوم الأحد على خادم الإنشاء القابل للشحن ومحليا بعد 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)

تحديث: يبدو أن سبب ذلك هو uglify-js كما يقول mgibas .

mgibas مع الحفظ: تحتوي ملفات معينة (ولكن ليس جميعها) في مكتبة ugllify-js على 1969 طابعًا زمنيًا . يجب أن يؤدي لمس هذه الملفات إلى تجاوز هذه العقبة السيئة.

في الواقع يبدو لي أن هناك مشكلة مع حزمة Webpack 's NPM. تم نشر الإصدار https://github.com/webpack/webpack/issues/5022

نعم ، يبدو أن uglify هو تبعية شائعة :)

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

sumothecat ليست مشكلة Webpack. إنها مشكلة في UglifyJS التي يستخدمها webpack. يحتاج المجتمع إلى توجيه أصابع الاتهام إلى الموقع الصحيح كما تم ربطه بواسطة

@ 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 ، فإن الحل المؤقت الذي نجح معي في الوقت الحالي بعد تثبيت الغزل أو تثبيت npm هو.

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

اختراق أكثر قوة لإضافته إلى ملف package.json :

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

سيؤدي هذا إلى touch لكل ملف يزيد عمره عن 30 عامًا بعد كل أمر npm install .

هل لا يزال أي شخص يعاني من هذه المشكلة؟
تم إصلاح الخطأ في NPM الذي يفسد mtime منذ ذلك الحين.
وتم إصدار جديد من UglifyJS نشر .

يبدو أيضًا أن هناك مشكلة في الوحدة النمطية ieee754 ، وهي تبعية aws-sdk . تم الإبلاغ عن هذه المشكلة: https://github.com/feross/ieee754/issues/17

رؤية نفس المشكلات ، بسبب @ slack / client npm هذه المرة.

على الرغم من وجود مشكلة بالتأكيد في تشويه بعض الطوابع الزمنية ، إلا أنني لا أرى سبب اهتمام أداة CLI هذه. ما سبب تسبب الطوابع الزمنية غير الصالحة في حدوث هذه المشكلة؟ هل هناك طريقة يمكن من خلالها دعمهم لتجنب هذه المشكلة تمامًا؟

كان لي نفس القضية. لقد جربت كل شيء ، لكن إعادة تشغيل الكمبيوتر المحمول فقط هي التي أدت إلى الحيلة.

نفس المشكلة وليست مشكلة uglify-js لأن لديّ أحدث إصدار من هذا lib.

كما هو مقترح أعلاه أنا فقط ركضت
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 {} \;
حل المشكلة.

لقد كانت هذه مشكلة متكررة في أجهزة عرض متعددة ذات تبعيات مختلفة.

ما زلت أواجه هذه المشكلة.

لقد واجهت هذه المشكلة أيضًا عندما أضفت مدينة نيويورك (اسطنبول) باعتبارها تبعية مطورة ، يبدو أنها أضافت uglify-js وهو السبب الجذري لهذه المشكلة.

من PoV الخاص بي ، يبدو أنه مرتبط بـ yarn على Mac.
عند استخدام npm على نظام Mac ، كل شيء على ما يرام.
عند استخدام yarn على Ubuntu ، كل شيء على ما يرام.
حتى مع وجود uglify-js والعديد من التبعيات الأخرى.
يمكن تجسيدها من خلال تجميع عالم الترحيب الخاص بـ AWS SAM (https://github.com/awslabs/aws-sam-cli/tree/develop#package-and-deploy-to-lambda).
عدا ذلك ، https://github.com/aws/aws-cli/issues/2639#issuecomment -391255985 تفعل الحيلة بشكل مثالي (ولكن يمكن أن تكون مكلفة مع العديد من الملفات)

نستخدم yarn --production الذي يتخطى جميع حزم devDependencies ، فهو يساعد في حل هذه المشكلة.

للأسف ، أنا أعتمد على عدد قليل من الحزم في الإنتاج والتي تسبب هذه المشكلة ، لذا فإن yarn --production لا يساعد.

ومع ذلك ، فإن yarn --production قبل إصلاح الطوابع الزمنية في node_modules/ يقلل بشكل كبير من وقت الإنشاء.

ما هو الأمر windows ل

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

لا يمكنني تشغيل هذا على جهاز الكمبيوتر الخاص بي

يبدو أنه كان من الممكن إصلاح ذلك باستخدام الوسيطة strict_timestamps من مكتبة zipfile python .