Cloud Container Builder，ZIP 不支持 1980 年之前的时间戳答案

【问题标题】：Cloud Container Builder, ZIP does not support timestamps before 1980Cloud Container Builder，ZIP 不支持 1980 年之前的时间戳
【发布时间】：2018-08-24 03:11:41
【问题描述】：

我正在尝试以下教程。

Automatic serverless deployments with Cloud Source Repositories and Container Builder

但是我得到了下面的错误。

$ gcloud container builds submit --config deploy.yaml .

BUILD
Already have image (with digest): gcr.io/cloud-builders/gcloud
ERROR: (gcloud.beta.functions.deploy) Error creating a ZIP archive with the source code for directory .: ZIP does not support timestamps before 1980
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/gcloud" failed: exit status 1

我现在正在尝试解决它。你有什么主意吗？我的 gcloud 是最新版本。

$ gcloud -v
Google Cloud SDK 193.0.0
app-engine-go 
app-engine-python 1.9.67
beta 2017.09.15
bq 2.0.30
core 2018.03.09
gsutil 4.28

教程中的谷歌云函数代码示例。

#index.js
exports.f = function(req, res) {
  res.send("hello, gcf!");
};

#deploy.yaml
steps:
- name: gcr.io/cloud-builders/gcloud
  args:
  - beta
  - functions
  - deploy
  - --trigger-http
  - --source=.
  - --entry-point=f
  - hello-gcf # Function name

#deploying without Cloud Container Builder is fine.
gcloud beta functions deploy --trigger-http --source=. --entry-point=f hello-gcf

【问题讨论】：

您的源文件中有哪些文件？（ls -alh）？旧文件是否来自教程？
在我的情况下，这是由于在本地构建 node.js 云功能进行测试后，不小心将节点模块目录包含在上传到 gcp 中，我想这是逐案的。跨度>

标签： google-app-engine google-cloud-platform google-cloud-functions google-container-registry google-container-builder

【解决方案1】：

虽然我不知道原因，但我找到了解决方法。

(1) make src directory and move index.js into it.

├── deploy.yaml
└── src
    └── index.js

(2) deploy via Cloud Container Builder.

$ gcloud container builds submit --config deploy.yaml ./src

【讨论】：

【解决方案2】：

Container Builder 会压缩您的源文件夹。也许你的 .目录有损坏的日期？这就是为什么将它移动到源文件夹可以修复它。

【讨论】：

【解决方案3】：

我现在遇到了同样的问题。我无法解决它，但至少我发现它来自哪里。当您在本地提交构建时，会创建一个 tar 并将其上传到存储桶。在此 tar 中，文件夹创建于 01.01.1970：

16777221 8683238 drwxr-xr-x 8 user staff 0 256 "Jan  1 01:00:00 1970" "Jan  1 01:00:00 1970" "May 15 12:42:04 2019" "Jan  1 01:00:00 1970" 4096 0 0 test

此问题仅在本地发生。如果你有一个 github 构建触发器，它可以工作

【讨论】：

【解决方案4】：

我最近在使用 Cloud Build（Container Builder 的后续产品）时遇到了同样的问题。

添加了一个步骤来列出 Cloud Build 环境中的所有文件/文件夹（默认目录为 /workspace）以识别有问题的文件/文件夹，这有助于识别问题。您可以通过覆盖gcloud 容器的入口点来执行ls 命令来执行此操作。

steps
  - name: gcr.io/cloud-builders/gcloud
    entrypoint: "ls"
    args: ["-la", "/workspace"]

【讨论】：