ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build XXXXXXXXXXXX status: FAILURE
Asked Answered
P

7

11

I had this error for almost an hour but found a solution resulting into a big worrying dilemma. The solution let to realization that one cannot run gcloud app deploy while there is a task in the task queue to be served by the server version to be replaced.

The error was: ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build XXXXXXXXXXXX status: FAILURE that xxxx part is some auto-generated base64 value.

The solution was: Deleting all the tasks in the task queue

Question: Is there workaround or I have to delete all the tasks in the task queue (like I did) before deploying?

Details: Server is written in nodejs.

Pentode answered 22/1, 2019 at 19:23 Comment(4)
Not the only reason for which re-deploying the same version (especially in production) is not a good idea, see #40193057Ingroup
Thanks @DanCornilescu that insight in the link was very helpful. I also think you should give another answer tailor-made for this Question since developers will search using the error message above and it largely varies from the one in the shared link even though the causes seem related as you mentioned therein.Pentode
Does the gcloud app deploy --no-promote generate version ID if the version ID not included in the command?Pentode
As you discovered - yesIngroup
I
0

I suspect that the need for emptying the task queues when tasks destined for the version being deleted could be driven by the virtual "head-of-the-line blocking" that would occur in this case, affecting other services/versions in the project (task queues are shared across a project) and maybe even the related GAE infra functionality.

Fundamentally re-writing a certain app/service version kinda defeats the whole purpose of versioning (imagine git allowing you to change the content of the commit/refpoint associated with a certain SHA signature!). But in some cases - for example when the version is actually used to implement a certain execution environment - that's intentional.

What you described is not the only issue with GAE deployments over-writing a certain version of an app/service (which I didn't think about before, BTW, thank you for that!). Another one is captured in Continuous integration/deployment/delivery on Google App Engine, too risky?.

If your deployments with version re-write are actually an attempt to implement deployment environments you may want to also look at a couple of other potential (IMHO better) alternatives compared in Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?

Ingroup answered 23/1, 2019 at 13:40 Comment(1)
Mmmm not sure how this will fix the problem.Whippletree
S
7
  1. You have to enable billing for your project.

Setup billing account

Subrogate answered 13/9, 2019 at 3:38 Comment(2)
I setup my billing account but didn't fix the problem.Whippletree
Also ensure to click on "validate" in the header pop-up if it appears to you.Vulcanite
N
2

I got the same issue, but this was due to my build failed. I went to the following link

https://console.cloud.google.com/cloud-build/builds?project=<your-project-name>

(substitute your project name)

and clicked on the failed build and check for the errors in the log.

after fixing that error my build worked fine.

Nubile answered 19/1, 2022 at 17:20 Comment(0)
S
1

I had the same problem, went back and properly insured the billing account was set properly and then it worked for me...

Straightforward answered 29/7, 2020 at 2:36 Comment(0)
V
1

I had to delete my package-lock.json because it was conflicting with the build. Once you rebuild, it will generate a new package-lock.json file for you.

Verda answered 1/5, 2023 at 15:18 Comment(0)
L
1

For me that happened after I freed some old builds from the Firebase storage but it did work with this command

gcloud app deploy /Users/path-to-my-project/src/main/webapp/WEB-INF/appengine-web.xml --no-cache

Replace your path-to-my-project and put the path of your appengine-web.xml file

Lemmie answered 4/4, 2024 at 4:19 Comment(0)
I
0

I suspect that the need for emptying the task queues when tasks destined for the version being deleted could be driven by the virtual "head-of-the-line blocking" that would occur in this case, affecting other services/versions in the project (task queues are shared across a project) and maybe even the related GAE infra functionality.

Fundamentally re-writing a certain app/service version kinda defeats the whole purpose of versioning (imagine git allowing you to change the content of the commit/refpoint associated with a certain SHA signature!). But in some cases - for example when the version is actually used to implement a certain execution environment - that's intentional.

What you described is not the only issue with GAE deployments over-writing a certain version of an app/service (which I didn't think about before, BTW, thank you for that!). Another one is captured in Continuous integration/deployment/delivery on Google App Engine, too risky?.

If your deployments with version re-write are actually an attempt to implement deployment environments you may want to also look at a couple of other potential (IMHO better) alternatives compared in Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?

Ingroup answered 23/1, 2019 at 13:40 Comment(1)
Mmmm not sure how this will fix the problem.Whippletree
U
0

This has happened once I upgraded from bash to zsh, adding #!/bin/bash to the top of the deployment script fixed the issue.

Unni answered 8/10, 2021 at 7:27 Comment(1)
How? explain plsChevaldefrise

© 2022 - 2025 — McMap. All rights reserved.