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 本身中引发的。

我今天在 create_application_revision 命令期间注意到与 CircleCI 完全相同的错误消息：

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

create_application_revision 已加载：{"applications":[{"region":"us-west-2","application_root":"/","re​​vision_location":{"s3Location":{"bucket":"“，“钥匙”：”"},"revisionType":"S3"},"deployment_group":"staging","application_name":""}]}
捆绑来自 /home/ubuntu/
未处理的异常
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)

更新：看起来这是由@mgibas所说的

@mgibas保存： ugllify-js库中的某些（但不是全部）文件上有 1969 年的时间戳。 触摸这些文件应该可以让您克服这个令人讨厌的障碍。

实际上在我看来是Webpack的 NPM 包的问题。 发布问题https://github.com/webpack/webpack/issues/5022

是的，似乎 uglify 是一个非常常见的依赖项:)

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

@sumothecat这不是 Webpack 的问题。 这是 webpack 使用的 UglifyJS 的一个问题。 社区需要将手指指向正确的位置，正如@mgibas所链接的

@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 的答案，在 yarn install 或 npm install 之后，现在对我有用的临时解决方案是。

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

将更强大的 hack 添加到您的package.json文件中：

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

这将touch每个npm install命令后

有人仍然有这个问题吗？
NPM 中破坏mtime已被修复。
并且已经发布了新版本的 UglifyJS。

ieee754模块似乎也有问题，它是aws-sdk的依赖项。 此问题已报告： https :

看到同样的问题，这次是由 @slack/client npm 引起的。

尽管某些时间戳确实存在问题，但我不明白为什么这个 CLI 工具应该关心。 无效时间戳导致此问题的原因是什么？ 有没有办法支持他们来完全避免这个问题？

我遇到过同样的问题。 我尝试了一切，但只有重新启动我的笔记本电脑才能成功。

同样的问题，它不是uglify-js问题，因为我有这个库的最新版本。

如上所述，我刚刚跑了
find ./node_modules/* -mtime +10950 -exec touch {} \;
在来自 proj 根目录的 vscode 终端上，它修复了它

eb deploy给了我

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
解决了这个问题。

对于具有不同依赖项的多个项目，这一直是一个反复出现的问题。

我仍然遇到这个问题。

当我添加 nyc (istanbul) 作为开发依赖项时也遇到了这个问题，看起来它添加了 uglify-js，这是这个问题的根本原因。

从我的 PoV 来看，它似乎与 Mac 上的yarn 。
在 Mac 上使用npm时一切正常。
在 Ubuntu 上使用yarn时一切正常。
即使有uglify-js和许多其他依赖项。
可以通过打包 AWS SAM 的 hello-world (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命令是干什么用的

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

我不能在我的电脑上运行这个

看起来这可以通过使用zipfile python library 中的strict_timestamps参数来解决。