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 다운그레이드한 후에도 (얼마 전에 작동하던) 동일한 오류가 발생합니다.

전체 빌드 로그

타임스탬프가 잘못된 파일이 있는 것 같습니다. 이것은 더 큰 문제를 나타낼 수 있으므로 수정하는 것이 좋습니다. python 자체에서 오류가 발생하기 때문에 CLI 버전을 변경해도 이에 영향을 미치지 않습니다.

오늘 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":"/","revision_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 with save: 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에서 문제를 닫았고 앞으로는 yarn lock 파일을 사용할 것입니다!

여기도 마찬가지입니다. 어떤 생각이 있으신가요?

내 응용 프로그램의 경우 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 {} \;

package.json 파일에 추가할 보다 강력한 해킹:

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

이렇게 하면 각 npm install 명령 후에 30년 이상 된 각 파일이 touch 됩니다.

아직도 이 문제가 있는 사람이 있습니까?
mtime 손상시키는 NPM의 버그가 수정 되었습니다.
그리고 UglifyJS의 새 버전이 게시 되었습니다.

또한 aws-sdk 의 종속성인 ieee754 모듈에 문제가 있는 것으로 보입니다. 이 문제가 보고되었습니다: https://github.com/feross/ieee754/issues/17

이번에는 @slack/client npm으로 인해 동일한 문제가 발생합니다.

일부 타임스탬프가 손상되는 문제는 분명히 있지만 이 CLI 도구가 왜 신경을 써야 하는지 모르겠습니다. 이 문제를 일으키는 잘못된 타임스탬프의 이유는 무엇입니까? 이 문제를 완전히 피하기 위해 지원될 수 있는 방법이 있습니까?

나는 같은 문제가 있었다. 나는 모든 것을 시도했지만 랩톱을 다시 시작하는 것만이 트릭이었습니다.

동일한 문제이며 이 라이브러리의 최신 버전이 있으므로 uglify-js 문제가 아닙니다.

위에서 제안한대로 방금 실행했습니다.
찾기 ./node_modules/* -mtime +10950 -exec 터치 {} \;
proj의 루트 디렉토리에서 vscode 터미널에서 수정했습니다.

eb deploy 줬어

ERROR: ValueError - ZIP does not support timestamps before 1980

find . -mtime +10950 -print -exec touch {} \;
문제를 해결했습니다.

이것은 종속성이 다른 여러 프로젝트에서 반복되는 문제였습니다.

나는 여전히이 문제가 발생합니다.

nyc(istanbul)를 dev 종속성으로 추가했을 때도 이 문제가 있었는데, 이 문제의 근본 원인인 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 트릭을 완벽하게 수행합니다(그러나 많은 파일에서 비용이 많이 들 수 있음)

우리는 모든 devDependencies 패키지를 건너뛰는 yarn --production 를 사용하여 이 문제를 해결하는 데 도움이 됩니다.

슬프게도 저는 이 문제를 일으키는 프로덕션의 몇 가지 패키지에 의존하므로 yarn --production 는 도움이 되지 않습니다.

즉, 말했다 yarn --production 에서 타임 스탬프를 고정하기 전에 node_modules/ 크게 빌드 시간을 줄일 않습니다.

Windows 명령은 무엇입니까

찾기 ./node_modules/* -mtime +10950 -exec 터치 {} \;

내 컴퓨터에서 실행할 수 없습니다

zipfile python library 의 strict_timestamps 인수를 사용하여 이 문제를 해결할 수 있었던 것 같습니다.