Aws-cli: Déploiement de code - Exception non gérée - ZIP ne prend pas en charge les horodatages antérieurs à 1980

Même erreur pour :
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

même après une rétrogradation à 1.11.79 (qui fonctionnait il y a quelque temps) donne la même erreur.

journal de construction complet

Il semble que vous ayez des fichiers avec des horodatages non valides. Cela pourrait indiquer un problème plus important, je recommanderais donc de les résoudre. La modification de votre version de la CLI n'aura pas d'impact car l'erreur est générée en python lui-même.

Je remarque exactement le même message d'erreur avec CircleCI aujourd'hui, lors de la commande create_application_revision :

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

create_application_revision chargé : {"applications":[{"region":"us-west-2","application_root":"/","revision_location":{"s3Location":{"bucket":"","clé":""},"revisionType":"S3"},"deployment_group":"staging","application_name":""}]}
Regroupementde /home/ubuntu/
Exception non-gérée
ZIP ne prend pas en charge les horodatages antérieurs à 1980

((create_application_revision "/tmp/codedeploy_applications.json" "/tmp/codedeploy_revisions.json")) a renvoyé le code de sortie 1
```

Il y a aussi un rapport de bogue ouvert sur les forums de support de CircleCI à ce sujet.

@JordonPhillips merci pour le retour rapide. Nous attendrons de voir si quelqu'un nous répondra sur le problème CircleCi. @arsenio - juste pour noter que nous avons déployé manuellement via le déploiement de code directement et cela a résolu le problème à court terme.

Donc pour moi, uglify-js obtenu des fichiers avec la date de création à 1969.
Comme solution de contournement, j'ai ajouté ceci:

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

Cela se produit aussi pour nous; depuis dimanche sur notre serveur de build Shippable et localement après un rm -rf node_modules

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

Ceci est une application nodejs, EB CLI 3.9.0 (Python 2.7.1)

Mise à jour : On dirait que cela est causé par uglify-js comme le dit @mgibas .

@mgibas avec la sauvegarde : certains fichiers (mais pas tous) de la bibliothèque ugllify-js ont un horodatage de 1969. Toucher ces fichiers devrait vous permettre de surmonter cet obstacle désagréable.

En fait, cela me semble être un problème avec le package NPM de Webpack . Problème publié https://github.com/webpack/webpack/issues/5022

Ouais, il semble que uglify soit une dépendance assez courante :)

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

@sumothecat ce n'est pas le problème de Webpack. C'est un problème avec UglifyJS que webpack utilise. La communauté doit pointer du doigt le bon endroit comme cela a été lié par @mgibas

@eric-tucker nous n'utilisons pas Uglify, mais Webpack en a une dépendance implicite. J'ai fermé le problème dans Webpack et j'utiliserai un fichier de verrouillage de fil à l'avenir !

Idem ici, des idées?

Pour mon application, jest et webpack apportaient la version corrompue de uglify-js .

Comme j'utilise déjà npm-shrinkwrap , j'ai ajouté les lignes suivantes à mon fichier 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"
    },

ce qui me permet de contourner temporairement ce problème.

En regardant la réponse mgibas, la solution temporaire qui a fonctionné pour moi pour le moment après une installation de fil ou une installation de npm est.

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

Hack plus robuste à ajouter à votre fichier package.json :

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

Cela va touch chaque fichier qui a plus de 30 ans après chaque commande npm install .

Est-ce que quelqu'un a encore ce problème ?
Le bogue dans NPM corrompant le mtime a depuis été corrigé .
Et une nouvelle version d'UglifyJS a été publiée .

Cela semble également être un problème avec le module ieee754 , qui est une dépendance de aws-sdk . Ce problème a été signalé : https://github.com/feross/ieee754/issues/17

voir les mêmes problèmes, causés par @slack/client npm cette fois.

Bien qu'il y ait certainement un problème avec certains horodatages qui sont mutilés, je ne vois pas pourquoi cet outil CLI devrait s'en soucier. Quelle est la raison des horodatages non valides à l'origine de ce problème ? Existe-t-il un moyen de les prendre en charge pour éviter complètement ce problème ?

J'ai eu le même problème. J'ai tout essayé, mais seul le redémarrage de mon ordinateur portable a fait l'affaire.

Même problème et ce n'est pas un problème de uglify-js puisque j'ai une dernière version de cette lib.

comme suggéré ci-dessus, je viens de courir
find ./node_modules/* -mtime +10950 -exec touch {} \;
sur le terminal vscode à partir du répertoire racine du proj et il l'a corrigé

eb deploy m'a donné

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
résolu le problème.

Cela a été un problème récurrent sur plusieurs projets avec différentes dépendances.

Je rencontre toujours ce problème.

Je viens d'avoir ce problème aussi lorsque j'ai ajouté nyc (istanbul) en tant que dépendance de développement, il semble qu'il ait ajouté uglify-js qui est la cause première de ce problème.

D'après mon PoV, cela semble lié à yarn sur Mac.
Lorsque vous utilisez npm sur Mac, tout va bien.
Lorsque vous utilisez yarn sur Ubuntu, tout va bien.
Même avec uglify-js et de nombreuses autres dépendances.
Il peut être démontré en empaquetant le hello-world d'AWS SAM (https://github.com/awslabs/aws-sam-cli/tree/develop#package-and-deploy-to-lambda).
Sinon, https://github.com/aws/aws-cli/issues/2639#issuecomment -391255985 fait parfaitement l'affaire (mais peut être coûteux avec de nombreux fichiers)

Nous utilisons yarn --production qui ignorent tous les devDependencies packages, cela aide à résoudre ce problème.

Malheureusement, je dépends de quelques packages en production qui causent ce problème, donc yarn --production n'aide pas.

Cela dit, yarn --production avant de corriger les horodatages dans node_modules/ réduit considérablement le temps de construction.

A quoi sert la commande windows

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

Je ne peux pas l'exécuter sur mon ordinateur

Il semble que cela aurait pu être corrigé en utilisant l'argument strict_timestamps de la bibliothèque zipfile python .