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 не повлияет на это, потому что ошибка возникает в самом python.

Я замечаю то же самое сообщение об ошибке с CircleCI сегодня во время команды create_application_revision:

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

create_application_revision загружено: {"приложения": [{"регион": "us-west-2", "application_root": "/", "revision_location": {"s3Location": {"bucket": "","ключ":""}," revisionType ":" S3 "}," deployment_group ":" staging "," application_name ":""}]}
Комплектацияиз / домой / убунту /
Необработанное исключение
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)

Обновление: похоже, что это вызвано uglify-js, как говорит @mgibas .

@mgibas с сохранением: некоторые (но не все) файлы в библиотеке ugllify-js имеют отметки времени 1969. Прикосновение к этим файлам должно помочь вам преодолеть это неприятное препятствие.

На самом деле мне кажется, что это проблема с пакетом NPM https://github.com/webpack/webpack/issues/5022

Да, похоже, что uglify - довольно распространенная зависимость :)

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

@sumothecat это не проблема Webpack. Это проблема с UglifyJS, который использует веб-пакет. Сообщество должно указывать пальцем в правильном месте, как было указано на

@ 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.

Хотя определенно существует проблема с искажением некоторых временных меток, я не понимаю, почему этот инструмент командной строки должен заботиться. В чем причина недействительных меток времени, вызывающих эту проблему? Есть ли способ их поддержать, чтобы полностью избежать этой проблемы?

Я была такая же проблема. Я пробовал все, но только перезагрузка ноутбука помогала.

Та же проблема, и это не проблема uglify-js поскольку у меня последняя версия этой библиотеки.

как было предложено выше, я только что побежал
найти ./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, это похоже на 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

найти ./node_modules/* -mtime +10950 -exec touch {} \;

Я не могу запустить это на своем компьютере

Похоже, это можно было исправить, используя аргумент strict_timestamps из библиотеки python zipfile .