Repository navigation
Support local builds for Cloud Run - #11207
Conversation
|
/gemini review |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for local builds and build-time environment variables/secrets for Cloud Run services, allowing services to be built locally using a base image and deployed directly from source. The feedback suggests improving robustness in deploy.ts by filtering out undefined environment variables during mapping and using a regular expression to split the run command to handle consecutive spaces correctly.
49d56c9 to
60f5d65
Compare
There was a problem hiding this comment.
Code Review
This pull request introduces support for local builds in Cloud Run deployments, allowing services to be built locally using App Hosting's local build utilities and resolving build-time secrets before deploying. It updates the deployment flow to package and upload the built application as a TAR archive, configure the container to run from the uploaded source on top of a base image, and manage build-time environment variables. Feedback on these changes includes wrapping cleanup fs.rmSync calls in try/catch blocks to prevent masking deployment or build errors, and using a more robust regex-based split (trim().split(/\s+/)) when parsing the run command to handle arbitrary whitespace safely.
# Conflicts: # src/deploy/run/deploy.spec.ts # src/init/features/run.ts
# Conflicts: # scripts/run-deploy-tests/tests.ts
Also adds the region to the local build messages, and suggests "firebase run:services:update <serviceId>:<region>" when a local build needs a base image.
Local builds now fit the four-step deploy: a revision runs either an image built on Cloud Build or a local build's uploaded output, and revisionTemplate (still pure) applies the local-build rules: the scratch image, the start command, runtime env vars, and switching back to an image. Those rules get small pure tests, and the local build archive is also left to tmp's delete-at-exit. Scratch folders are still deleted right away.
# Conflicts: # src/deploy/run/update.spec.ts # src/deploy/run/util.ts
Build-time env vars and secrets (the buildConfig.environmentVariablesAndSecrets annotation) move to bapi_build_env, so this PR only adds local builds.
- deploy() creates the scratch folder and deletes it in one finally. - Explain the App Hosting Backend that the Node.js version check needs. - Init's base image validation is one expression.
- deploy: split the end-to-end local build test, stub the scratch folder instead of touching the filesystem, and keep #11205's upload stub. - prepare: drop a test of an implementation detail. - init: answer prompts with one helper, one behavior per test, and split the upsertRunConfig localBuild test into on and off.
Also set localBuild in init with if statements instead of conditional spreads.
# Conflicts: # src/deploy/run/update.ts
# Conflicts: # src/deploy/run/args.ts
deploy() now calls deployRemoteBuild or deployLocalBuild. Each path has its own upload function, and local builds get their own revision template, so there are no more RevisionCode unions or repeated localBuild ternaries. The local build's output is passed between functions instead of being stored on ServiceDeploy. The local build guard's fix now uses run:services:update's --region flag.
The env vars a build reports describe that build's output, like its start command, so they now replace any env var of the same name on the service instead of being skipped. The service's other env vars are kept.
falahat
changed the title
3 participants
Description
With
"localBuild": truein firebase.json,firebase deploybuilds the app locally with App Hosting's tooling and uploads the output. Cloud Run runs it on the service's base image, with no Cloud Build.deploy.ts: splits intodeployRemoteBuild(the existing flow) anddeployLocalBuild. The build's start command and env vars overwrite the service's.prepare.ts,update.ts: local builds require a base image.init/features/run.ts: asks whether to build locally or remotely, and saves the answer aslocalBuild.Next in the stack: #11266 (build env), then #11208 (SDK auto-init).
Scenarios Tested
Sample Commands