firebase-tools
firebase-tools copied to clipboard
Error Adjusting Traffic to Previous Cloud Run Revisions Deployed via Firebase CLI(Cloud Functions)
Environment info
firebase-tools: 13.2.1 Platform: macOS 14.0 (23A344)
Test case
A Cloud Run service deployed via Cloud Functions, where deployments are triggered through the Firebase CLI. The service experiences failures when attempting to route traffic back to previous revisions, receiving errors related to fetching container image metadata from Google Artifact Registry.
Steps to reproduce
- Deploy Cloud Functions that trigger updates to a Cloud Run service using the Firebase CLI with the following command:
firebase deploy
- Confirm the deployment is successful and the new revision is serving traffic.
- Attempt to adjust traffic back to a previous revision using either the Google Cloud Console or the gcloud CLI:
gcloud run services update-traffic "SERVICE_NAME" --region "europe-central2" --to-revisions "PREVIOUS_REVISION=100"
- Observe the error message indicating the failure due to the inability to fetch metadata for the container image from the Artifact Registry.
Expected behavior
It should be possible to adjust traffic to any revision of the Cloud Run service deployed via Firebase CLI without encountering errors related to container image imports. Adjusting traffic should be seamless across revisions, allowing for flexible traffic management and rollback capabilities.
Actual behavior
When trying to adjust traffic to a previous revision of a Cloud Run service deployed via Firebase CLI, the operation fails with an error related to fetching metadata for the container image from Google Artifact Registry. The error specifically states that the container image cannot be imported because the metadata cannot be fetched, implying that the image or its manifest could not be found.
Error Message:
Container import failed:
This issue consistently manifests across all Cloud Run services when deployment and subsequent revisions are managed through Cloud Functions triggered by Firebase CLI deployments. Notably, this challenge does not extend to deployments executed directly through the gcloud CLI. Extensive testing with the gcloud CLI for deploying similar Cloud Run services and adjusting traffic between revisions yields the expected outcomes, with no errors encountered. This contrast underscores a potential discrepancy or bug specifically associated with the Firebase CLI's handling or configuration of Cloud Run service revisions, which does not seem to properly maintain or reference the container images for previous revisions in the Google Artifact Registry. The successful deployment and traffic adjustments using the gcloud CLI affirm that the underlying Cloud Run and Google Artifact Registry configurations are correct and suggest the issue is isolated to Firebase CLI deployments.
Upon further investigation, I've noticed a potentially significant difference in how firebase deploy and gcloud deploy manage Docker container images in the Artifact Registry. Specifically, when deploying Cloud Functions via firebase deploy, it appears that the associated Docker container image in the Artifact Registry is removed post-deployment.In contrast, deployments carried out using gcloud deploy do not exhibit this behavior; the Docker container images remain intact within the Artifact Registry post-deployment.