Aws-cli: Implementación de código: excepción no controlada: ZIP no admite marcas de tiempo anteriores a 1980

Mismo error para:
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

incluso después de degradar a 1.11.79 (que estaba funcionando hace algún tiempo) da el mismo error.

registro de compilación completo

Parece que tiene algunos archivos con marcas de tiempo no válidas. Esto podría ser indicativo de un problema mayor, por lo que recomendaría solucionarlo. Cambiar su versión de la CLI no afectará esto porque el error se genera en Python.

Hoy noto exactamente el mismo mensaje de error con CircleCI, durante el comando create_application_revision:

`` crear_application_revision /tmp/codedeploy_applications.json /tmp/codedeploy_revisions.json

create_application_revision cargado: {"applications": [{"region": "us-west-2", "application_root": "/", "revision_location": {"s3Location": {"bucket": "","llave":""}," revisionType ":" S3 "}," deployment_group ":" staging "," application_name ":""}]}
Agrupacióndesde / home / ubuntu /
Excepción no controlada
ZIP no admite marcas de tiempo anteriores a 1980

((create_application_revision "/tmp/codedeploy_applications.json" "/tmp/codedeploy_revisions.json")) devolvió el código de salida 1
''

También hay un Informe de error abierto en los foros de soporte de CircleCI sobre esto.

@JordonPhillips gracias por los comentarios rápidos. Esperaremos a ver si alguien se comunica con nosotros sobre el problema de CircleCi. @arsenio -sólo para tener en cuenta que implementamos manualmente a través de la implementación de código directamente y esto resolvió el problema a corto plazo.

Entonces, para mí, uglify-js tiene archivos con fecha de creación en 1969.
Como solución, agregué esto:

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

Esto también nos está sucediendo a nosotros; desde el domingo en nuestro servidor de compilación que se puede enviar y localmente después de un rm -rf node_modules

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

Esta es una aplicación de nodejs, EB CLI 3.9.0 (Python 2.7.1)

Actualización: parece que esto está siendo causado por uglify-js como dice @mgibas .

@mgibas con guardar: ciertos archivos (pero no todos) en la biblioteca ugllify-js tienen 1969 marcas de tiempo. Tocar esos archivos debería superar este desagradable obstáculo.

En realidad, me parece un problema con el paquete NPM de Webpack . Problema publicado https://github.com/webpack/webpack/issues/5022

Sí, parece que uglify es una dependencia bastante común :)

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

@sumothecat no es un problema de Webpack. Es un problema con UglifyJS que utiliza el paquete web. La comunidad debe señalar con el dedo en la ubicación correcta, como lo ha vinculado @mgibas

@ eric-tucker no usamos Uglify, pero Webpack tiene una dependencia implícita de él. ¡Cerré el problema en Webpack y usaré un archivo de bloqueo de hilo en el futuro!

Lo mismo aquí, ¿alguna idea?

Para mi aplicación, tanto jest como webpack traían la versión dañada de uglify-js .

Como ya uso npm-shrinkwrap , agregué las siguientes líneas a mi archivo 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"
    },

lo que me permitió solucionar este problema temporalmente.

En cuanto a la respuesta de mgibas, la solución temporal que funcionó para mí por ahora después de una instalación de hilo o una instalación de npm es.

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

Truco más robusto para agregar a su archivo package.json :

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

Esto touch cada archivo que tenga más de 30 años después de cada comando npm install .

¿Alguien sigue teniendo este problema?
El error en NPM que corrompe el mtime se ha solucionado desde entonces.
Y se ha publicado una nueva versión de UglifyJS.

También parece ser un problema con el módulo ieee754 , que es una dependencia de aws-sdk . Se ha informado de este problema: https://github.com/feross/ieee754/issues/17

viendo los mismos problemas, debido a @ slack / client npm esta vez.

Aunque definitivamente hay un problema con algunas marcas de tiempo que se alteran, no veo por qué a esta herramienta CLI debería importarle. ¿Cuál es el motivo de las marcas de tiempo no válidas que provocan este problema? ¿Hay alguna manera de que puedan recibir asistencia para evitar por completo este problema?

Tuve el mismo problema. Intenté todo, pero solo reiniciar mi computadora portátil funcionó.

El mismo problema y no es un problema de uglify-js ya que tengo la última versión de esta lib.

como se sugirió anteriormente, acabo de correr
buscar ./node_modules/* -mtime +10950 -exec touch {} \;
en el terminal vscode desde el directorio raíz del proyecto y lo solucionó

eb deploy me dio

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
resuelve el problema.

Este ha sido un problema recurrente en múltiples proyectos con diferentes dependencias.

Todavía me encuentro con este problema.

También tuve este problema cuando agregué nyc (istanbul) como una dependencia de desarrollo, parece que agregó uglify-js, que es la causa raíz de este problema.

Desde mi punto de vista, parece estar relacionado con yarn en Mac.
Al usar npm en Mac, todo está bien.
Al usar yarn en Ubuntu, todo está bien.
Incluso con uglify-js y muchas otras dependencias.
Se puede realizar una demostración empaquetando el hello-world de AWS SAM (https://github.com/awslabs/aws-sam-cli/tree/develop#package-and-deploy-to-lambda).
De lo contrario, https://github.com/aws/aws-cli/issues/2639#issuecomment -391255985 hace perfectamente el truco (pero puede ser costoso con muchos archivos)

Usamos yarn --production que omiten todos los paquetes devDependencies , esto ayuda a resolver este problema.

Lamentablemente, dependo de algunos paquetes en producción que causan este problema, por lo que yarn --production no ayuda.

Dicho esto, yarn --production antes de arreglar las marcas de tiempo en node_modules/ reduce significativamente el tiempo de compilación.

¿Para que sirve el comando de Windows?

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

No puedo ejecutar esto en mi computadora

Parece que esto podría haberse solucionado usando el argumento strict_timestamps de la biblioteca de python zipfile .