Aws-cli: Implementação de código - exceção não tratada - ZIP não oferece suporte a carimbos de data / hora antes de 1980

Mesmo erro 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

mesmo depois de fazer o downgrade para 1.11.79 (que estava funcionando há algum tempo) dá o mesmo erro.

log de compilação completo

Parece que você tem alguns arquivos com carimbos de data / hora inválidos. Isso pode ser um indicativo de um problema maior, então eu recomendo corrigi-los. Alterar sua versão da CLI não afetará isso porque o erro é gerado no próprio python.

Estou percebendo exatamente a mesma mensagem de erro com o CircleCI hoje, durante o comando create_application_revision:

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

create_application_revision carregado: {"applications": [{"region": "us-west-2", "application_root": "/", "revision_location": {"s3Location": {"bucket": "","chave":""}," revisionType ":" S3 "}," deployment_group ":" staging "," application_name ":""}]}
Empacotamentode / home / ubuntu /
Exceção não tratada
ZIP não oferece suporte a carimbos de data / hora anteriores a 1980

((create_application_revision "/tmp/codedeploy_applications.json" "/tmp/codedeploy_revisions.json")) retornou o código de saída 1
`` `

Há também um relatório de bug aberto nos fóruns de suporte do CircleCI sobre isso.

@JordonPhillips, obrigado pelo feedback rápido. Vamos esperar para ver se alguém nos responde sobre a questão do CircleCi. @arsenio - apenas para notar que implementamos manualmente via code deploy diretamente e isso resolveu o problema a curto prazo.

Então, para mim, uglify-js obteve arquivos com data de criação em 1969.
Como solução alternativa, adicionei o seguinte:

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

Isso está acontecendo para nós também; desde domingo em nosso servidor de compilação Shippable e localmente após um rm -rf node_modules

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

Este é um aplicativo nodejs, EB CLI 3.9.0 (Python 2.7.1)

Atualização: Parece que isso está sendo causado por uglify-js, como diz @mgibas .

@mgibas com o save: certos (mas não todos) arquivos na biblioteca ugllify-js possuem 1969 carimbos de data / hora. Tocar nesses arquivos deve superar esse obstáculo desagradável.

Na verdade, parece-me um problema com o pacote NPM do Webpack . Problema publicado https://github.com/webpack/webpack/issues/5022

Sim, parece que o uglify é uma dependência bastante comum :)

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

@sumothecat não é problema do Webpack. É um problema com o UglifyJS que o webpack usa. A comunidade precisa apontar o dedo sobre o local correto, conforme linkado por @mgibas

@ eric-tucker não usamos Uglify, mas Webpack tem uma dependência implícita dele. Eu fechei o problema no Webpack e estarei usando um arquivo de bloqueio de yarn no futuro!

O mesmo aqui, algum pensamento?

Para meu aplicativo, jest e webpack traziam a versão corrompida de uglify-js .

Como já uso npm-shrinkwrap , adicionei as seguintes linhas ao meu arquivo 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"
    },

o que me permite contornar esse problema temporariamente.

Olhando para a resposta do mgibas, a solução temporária que funcionou para mim por enquanto após a instalação do yarn ou instalação do npm é.

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

Hack mais robusto para adicionar ao seu arquivo package.json :

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

Isso irá touch cada arquivo com mais de 30 anos após cada comando npm install .

Alguém ainda está tendo esse problema?
O bug no NPM que corrompia o mtime foi corrigido .
E uma nova versão do UglifyJS foi publicada .

Também parece haver um problema com o módulo ieee754 , que é uma dependência de aws-sdk . Este problema foi relatado: https://github.com/feross/ieee754/issues/17

vendo os mesmos problemas, causados ​​por @ slack / client npm neste momento.

Embora haja definitivamente um problema com alguns carimbos de data / hora sendo mutilados, não vejo por que essa ferramenta CLI deveria se importar. Qual é o motivo para carimbos de data / hora inválidos causando esse problema? Existe uma maneira de eles serem apoiados para evitar totalmente esse problema?

Eu tive o mesmo problema. Tentei de tudo, mas apenas reiniciar meu laptop funcionou.

Mesmo problema e não é um problema de uglify-js , pois tenho uma versão mais recente desta biblioteca.

como sugerido acima, acabei de correr
find ./node_modules/* -mtime +10950 -exec touch {} \;
no terminal vscode do diretório raiz do proj e ele corrigiu

eb deploy me deu

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
resolveu o problema.

Este tem sido um problema recorrente em vários projetos com dependências diferentes.

Eu ainda encontro esse problema.

Também tive esse problema quando adicionei nyc (istanbul) como uma dependência dev, parece que foi adicionado uglify-js, que é a causa raiz desse problema.

No meu PoV, parece relacionado a yarn no Mac.
Ao usar npm no Mac está tudo bem.
Ao usar yarn no Ubuntu está tudo bem.
Mesmo com uglify-js e muitas outras dependências.
Ele pode ser demonstrado empacotando o hello-world do AWS SAM (https://github.com/awslabs/aws-sam-cli/tree/develop#package-and-deploy-to-lambda).
Caso contrário, https://github.com/aws/aws-cli/issues/2639#issuecomment -391255985 faz perfeitamente o truque (mas pode ser caro com muitos arquivos)

Usamos yarn --production que ignoram todos os devDependencies pacotes, isso ajuda a resolver este problema.

Infelizmente, dependo de alguns pacotes em produção que causam esse problema, então yarn --production não ajuda.

Dito isso, yarn --production antes de fixar os carimbos de data / hora em node_modules/ diminui significativamente o tempo de compilação.

Para que serve o comando do Windows

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

Eu não consigo executar isso no meu computador

Parece que isso pode ter sido corrigido usando o argumento strict_timestamps da biblioteca zipfile python .