angular - Google Cloud Build - firebase 部署错误 : "public directory ' dist/browser' does not exist, 无法将托管部署到站点 PROJECT-ID”

Question

我正在尝试将我的 Angular 通用网络应用程序同时部署到 Cloud Run(用于 SSR)和 Firebase 托管(用于缓存)。部署到 Cloud Run 工作正常，我按照本指南 (https://cloud.google.com/build/docs/deploying-builds/deploy-firebase#using_the_firebase_community_builder) 使用 Google Cloud Build 启用 Firebase 部署。

但是，每当我运行 gcloud builds submit --config=cloudbuild.yaml 时出现错误:public directory 'dist/browser' does not exist, can't deploy hosting to site PROJECT -ID 在 cloudbuild.yaml 中的 Firebase 部署步骤中抛出。

cloudbuild.yaml:

steps:
  # build image
  - name: 'gcr.io/cloud-builders/docker'
    args: [ 'build', '-t', 'gcr.io/PROJECT-ID/SERVICE-ID', '.' ]
  # push image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/PROJECT-ID/SERVICE-ID']
  # deploy to Cloud Run
  - name: "gcr.io/cloud-builders/gcloud"
    args: [ "run", "deploy", "SERVICE-ID", "--image", "gcr.io/PROJECT-ID/SERVICE-ID", "--region", "us-central1", "--platform", "managed", "--allow-unauthenticated" ]
  # deploy to Firebase (ERROR HAPPENS HERE Specified public directory 'xx' does not exist, can't deploy hosting to site PROJECT-ID)
  - name: gcr.io/PROJECT-ID/firebase
    args: ['deploy', '--project=PROJECT-ID', '--only=hosting']
images:
  - 'gcr.io/PROJECT-ID/SERVICE-ID'
timeout: 1800s
substitutions:
  _ENV_VARIABLE: development

Dockerfile

FROM node:14

# set work directory
WORKDIR usr/src/app

# copy package.json and package-lock
COPY package*.json ./

# install dependencies
RUN npm install

# copy local code to container
COPY . .

# build app
RUN npm run build:ssr

# serve app
CMD ["npm", "run", "serve:ssr"]

firebase.json

{
...
  "hosting": [
    {
      "public": "dist/browser",
      "ignore": [
        "**/.*"
      ],
      ...
    }
  ]
...
}

错误日志

DEBUG: https://storage.googleapis.com:443 "GET /987290120943.cloudbuild-logs.googleusercontent.com/log-93082fbf-1b87-499a-9132-fed5f1c06aad.txt HTTP/1.1" 206 290
DEBUG: Reading GCS logfile: 206 (read 290 bytes)
Step #3:
Step #3: ←[1m←[37m===←[39m Deploying to 'PROJECT-ID'...←[22m
Step #3:
Step #3: ←[1m←[36mi ←[39m←[22m deploying ←[1mhosting←[22m
Step #3:
Step #3: ←[1m←[31mError:←[39m←[22m Specified public directory 'dist/browser' does not exist, can't deploy hosting to site PROJECT-ID
DEBUG: https://cloudbuild.googleapis.com:443 "GET /v1/projects/PROJECT-ID/locations/global/builds/93082fbf-1b87-499a-9132-fed5f1c06aad?alt=json HTTP/1.1" 200 None
DEBUG: https://storage.googleapis.com:443 "GET /987290120943.cloudbuild-logs.googleusercontent.com/log-93082fbf-1b87-499a-9132-fed5f1c06aad.txt HTTP/1.1" 206 120
DEBUG: Reading GCS logfile: 206 (read 120 bytes)
Finished Step #3
ERROR
ERROR: build step 3 "gcr.io/PROJECT-ID/firebase" failed: step exited with non-zero status: 1
DEBUG: https://storage.googleapis.com:443 "GET /987290120943.cloudbuild-logs.googleusercontent.com/log-93082fbf-1b87-499a-9132-fed5f1c06aad.txt HTTP/1.1" 416 168
DEBUG: Reading GCS logfile: 416 (no new content; keep polling)

由于在本地一切正常，我认为它可能必须对 gcr.io/PROJECT-ID/firebase 与服务 gcr.io/位于不同的容器中做一些事情PROJECT-ID/SERVICE-ID 可能会在其中创建 dist 文件夹。

编辑#1:

我测试了在项目的根目录中创建一个名为“static”的文件夹，并将 firebase.json 中的 public 属性更改为“static”。它起作用了，这让我相信由于某种原因 dist/browser 目录在 cloudbuild.yaml 的“部署到 Firebase”步骤中不存在，即使它是创建的在 Dockerfile 的 RUN npm run build:ssr 期间。

编辑#2:

我在类似的问题上发现了一些不够充分的东西(https://stackoverflow.com/a/64215324/8581106)。但是，建议似乎还需要在 cloudbuild.yaml 中部署 Firebase 之前运行构建命令 npm run build:ssr 以确保 dist/browser 目录存在。但我真的很想避免在 Cloud Run 上提供一个构建并将一个新构建部署到 Firebase，因为 Angular 每次都对 .js 和 .css 文件使用唯一的哈希我觉得这可能会导致缓存问题。

编辑#3:

我创建了一个图像来更好地可视化我的问题(见下图)。我是 docker 和 Cloud Build 的新手，但我觉得这是我运行 gcloud builds submit --config=cloudbuild.yaml 时的过程。我不明白为什么 dist/browser 存在于 Dockerfile 范围内，但不存在于 cloudbuild.yaml 范围内。

Answer 1

根据 https://stackoverflow.com/a/66714846/8581106 ，我无法访问 cloudbuild.yaml 中的 dist/browser 目录，因为该目录是通过 Dockerfile 在不同的上下文中创建的。

目前，我找到的唯一解决方案是在将构建部署到 Cloud Run 后立即将一个空文件夹部署到 Firebase 托管。据我了解，用户现在向 Firebase 托管发出请求并获得响应(如果它已经缓存在 Firebase 托管服务器上)。如果请求的数据未缓存，则 firebase.json 中的 rewrites 允许从 Cloud Run 获取呈现的数据并在可能的情况下缓存它。

虽然它似乎有效，但我不知道来自 Cloud Run 的文件是否正确缓存在 Firebase 托管上，此外，Lighthouse 在性能方面的得分要差得多，因为缺少对文本、图像和之前由 Firebase Hosting 自动管理的文件。不过，目前这是最可行的解决方案。