Aws-cli: Code Deploy - Unbehandelte Ausnahme - ZIP unterstützt keine Zeitstempel vor 1980

Gleicher Fehler für:
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

selbst nach einem Downgrade auf 1.11.79 (das vor einiger Zeit funktionierte) wird der gleiche Fehler angezeigt.

vollständiges Build-Log

Es hört sich so an, als ob Sie einige Dateien mit ungültigen Zeitstempeln haben. Dies könnte auf ein größeres Problem hinweisen, daher würde ich empfehlen, sie zu beheben. Das Ändern Ihrer Version der CLI hat keinen Einfluss darauf, da der Fehler in Python selbst ausgelöst wird.

Ich bemerke heute genau die gleiche Fehlermeldung bei CircleCI während des Befehls create_application_revision:

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

create_application_revision geladen: {"applications":[{"region":"us-west-2","application_root":"/","revision_location":{"s3Location":{"bucket":"","Schlüssel":""},"revisionType":"S3"},"deployment_group":"staging","application_name":""}]}
Bündelungvon /home/ubuntu/
Unbehandelte Ausnahme
ZIP unterstützt keine Zeitstempel vor 1980

((create_application_revision "/tmp/codedeploy_applications.json" "/tmp/codedeploy_revisions.json")) hat Exitcode 1 zurückgegeben
```

Es gibt auch einen Bug Report offen auf CircleCI die Support - Foren darüber.

@JordonPhillips danke für das schnelle Feedback. Wir warten ab, ob sich jemand zum CircleCi-Problem meldet. @arsenio -nur um zu bemerken, dass wir manuell über Code-Deployment direkt bereitgestellt haben und dies das Problem kurzfristig gelöst hat.

Also für mich hat uglify-js Dateien mit dem Erstellungsdatum 1969.
Als Workaround habe ich folgendes hinzugefügt:

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

Dies geschieht auch bei uns; seit Sonntag auf unserem Shippable Build Server und lokal nach einem rm -rf node_modules

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

Dies ist eine nodejs-App, EB CLI 3.9.0 (Python 2.7.1)

Update: Sieht so aus, als ob dies von uglify-js verursacht wird, wie @mgibas sagt.

@mgibas mit dem Speichern: Bestimmte (aber nicht alle) Dateien in der ugllify-js Bibliothek haben 1969-Zeitstempel. Wenn Sie diese Dateien berühren, sollten Sie diese unangenehme Hürde überwinden.

Scheint mir eigentlich ein Problem mit dem NPM-Paket von Webpack zu sein . Gepostete Ausgabe https://github.com/webpack/webpack/issues/5022

Ja, anscheinend ist Uglify eine ziemlich häufige Abhängigkeit :)

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

@sumothecat es ist nicht das Problem von Webpack. Es ist ein Problem mit UglifyJS, das Webpack verwendet. Die Community muss mit dem Finger auf die richtige Stelle zeigen, wie von @mgibas verlinkt wurde

@eric-tucker wir verwenden Uglify nicht, aber Webpack hat eine implizite Abhängigkeit davon. Ich habe das Problem in Webpack geschlossen und werde in Zukunft eine Garnlock-Datei verwenden!

Das gleiche hier, irgendwelche Gedanken?

Für meine Anwendung brachten sowohl jest als auch webpack die beschädigte Version von uglify-js .

Da ich npm-shrinkwrap bereits verwende, habe ich meiner Datei npm-shrinkwrap.json die folgenden Zeilen hinzugefügt:

"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"
    },

wodurch ich dieses Problem vorübergehend umgehen kann.

Wenn Sie sich die Antwort von mgibas ansehen, ist die temporäre Lösung, die für mich nach einer Garninstallation oder einer NPM-Installation funktioniert hat.

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

Robusterer Hack zum Hinzufügen zu Ihrer package.json Datei:

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

Dies wird touch jede Datei, die älter als 30 Jahre ist, nach jedem npm install Befehl.

Hat noch jemand dieses Problem?
Der Fehler in NPM, der das mtime beschädigt, wurde inzwischen behoben .
Und eine neue Version von UglifyJS wurde veröffentlicht .

Scheint auch ein Problem mit dem ieee754 Modul zu sein, das eine Abhängigkeit von aws-sdk . Dieses Problem wurde gemeldet: https://github.com/feross/ieee754/issues/17

sehen die gleichen Probleme, diesmal verursacht durch @slack/client npm.

Obwohl es definitiv ein Problem mit einigen Zeitstempeln gibt, die verstümmelt werden, sehe ich nicht, warum dieses CLI-Tool sich darum kümmern sollte. Was ist der Grund für ungültige Zeitstempel, die dieses Problem verursachen? Gibt es eine Möglichkeit, sie zu unterstützen, um dieses Problem vollständig zu vermeiden?

Ich hatte das gleiche Problem. Ich habe alles versucht, aber nur ein Neustart meines Laptops hat geholfen.

Das gleiche Problem und es ist kein uglify-js Problem, da ich eine neueste Version dieser Bibliothek habe.

wie oben vorgeschlagen bin ich gerade gelaufen
find ./node_modules/* -mtime +10950 -exec touch {} \;
auf dem vscode-Terminal aus dem Root-Verzeichnis des Projekts und es wurde behoben

eb deploy gab mir

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
Problem gelöst.

Dies ist ein wiederkehrendes Problem in mehreren Projekten mit unterschiedlichen Abhängigkeiten.

Ich stoße immer noch auf dieses Problem.

Hatte dieses Problem auch gerade, als ich nyc (istanbul) als Dev-Abhängigkeit hinzufügte, es sieht so aus, als ob es uglify-js hinzugefügt hätte, was die Hauptursache für dieses Problem ist.

Von meinem Standpunkt aus scheint es mit yarn auf dem Mac zu tun zu haben.
Bei Verwendung von npm auf dem Mac ist alles in Ordnung.
Bei Verwendung von yarn unter Ubuntu ist alles in Ordnung.
Sogar mit uglify-js und vielen anderen Abhängigkeiten.
Es kann demonstriert werden, indem man die hello-world von AWS SAM (https://github.com/awslabs/aws-sam-cli/tree/develop#package-and-deploy-to-lambda) packt.
Andernfalls tun https://github.com/aws/aws-cli/issues/2639#issuecomment -391255985 den Trick perfekt (kann aber bei vielen Dateien teuer werden)

Wir verwenden yarn --production , das alle devDependencies Pakete überspringt. Es hilft, dieses Problem zu lösen.

Leider bin ich auf ein paar Pakete in der Produktion angewiesen, die dieses Problem verursachen, also hilft yarn --production nicht.

Das heißt, yarn --production vor dem Korrigieren von Zeitstempeln in node_modules/ verkürzt die Buildzeit erheblich.

Wozu dient der Windows-Befehl?

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

Ich kann das auf meinem Computer nicht ausführen

Es sieht so aus, als hätte dies mit dem Argument strict_timestamps aus der Zipfile-Python-Bibliothek behoben werden können.