首页 > 解决方案 > 使用 WINDOWS OS 10 中的 Google Cloud SDK 部署 Google App Engine 柔性环境失败

问题描述

我在 CodeIgniter 框架中开发的生产站点,它有超过 10k 个文件,我上周成功部署,没有任何问题。今天我的部署失败了,我只是更正了脚本中的一个查询。

我有以下问题

C:\myproject>gcloud app deploy --version 13 app.yaml
Services to deploy:

descriptor:      [C:\myproject\app.yaml]
source:          [C:\myproject]
target project:  [xyz]
target service:  [uat]
target version:  [13]
target url:      [https://uat-dot-xyz.appspot.com]


Do you want to continue (Y/n)?  Y
    Beginning deployment of service [uat]...
    #============================================================#
    #= Uploading 0 files to Google Cloud Storage                =#
    #============================================================#
    File upload done.
    ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: This deployment has too many files. New versions are limited to 10000 files for this app.
    - '@type': type.googleapis.com/google.rpc.BadRequest
      fieldViolations:
      - description: This deployment has too many files. New versions are limited to 10000
          files for this app.
        field: version.deployment.files[...]

我提到了下面的SO帖子

gcloud app deploy 失败,因为部署中有太多用于 PHP CodeIgnitor 文件的文件

gcloud app deploy :此部署文件过多 克服 Google App Engine 上 10000 个文件限制的方法?

谷歌应用引擎服务之间的通信

我按照以下启用了 .gcloudignore 文件并在 myproject 中创建

https://cloud.google.com/sdk/gcloud/reference/topic/gcloudignore

如何在 .gcloudignore 中包含在 .gitignore 中被忽略的文件

C:\>gcloud config set gcloudignore/enabled true
Updated property [gcloudignore/enabled].

C:\>gcloud config list
[accessibility]
screen_reader = False
[compute]
region = region-name
zone = zone-name
[core]
account = xyz@domainname.com
disable_usage_reporting = True
project = xyz
[gcloudignore]
enabled = true

我当前的 Cloud SDK 版本是:320.0.0

从版本安装组件:320.0.0

我找不到解决方案。为什么突然我的部署失败了使用 Gcloud SDK 到 GAE 灵活环境(注:我的项目有超过 10 k 的文件,直到上周我没有得到这个问题)

请帮我解决这个问题,如果我错过了任何东西,在此先感谢。

标签: codeignitergoogle-app-enginegoogle-cloud-platformapp-engine-flexiblegoogle-cloud-sdk

解决方案


看起来 App Engine 部署文件的方式发生了变化。

运行命令gcloud config set app/trigger_build_server_side false解决了问题

现在在 12 月 15 日,此更改似乎已恢复,正常部署应该像以前一样工作


推荐阅读