Adding Timeout field causes GCloud Build to Fail, what is the correct method to increase timeout

Question

My gcloud build will timeout if left at the default timeout of 10 minutes, so I have tried to increase the timeout to 20 minutes. This is my cloudbuild.yaml.

    # cloudbuild.yaml
    steps:
    - name: node:14.17.1
      entrypoint: npm
      args: ["install"]
    - name: node:14.17.1
      entrypoint: npm
      args: ["run", "build"]
    - name: "gcr.io/cloud-builders/gcloud"
      args: ["app", "deploy"]
    timeout: 1200s

It processes Step 0 and Step 1 and fails at Step 2, which is gcloud app deploy. The execution log reports the following error:

ERROR: gcloud crashed (InvalidBuildError): Field [timeout] was provided, but should not have been. You may be using an improper Cloud Build pipeline.

All the documentation I've says that this is how you increase the timeout, some say the the timeout needs to be wrapped in single quotes, but this doesn't appear to be true as if I review the Execution details, it correctly identifies that the timeout is 20 minutes. Trying with single quotes makes no difference to the outcome.

I've also tried setting a timeout at the app deploy step as well, but it produces the same error and would be ineffectual anyway as it is the entire build process that is exceeding the execution time if left at default.

Your logic is sound and it should work. I suspect a bug. Have you tried reordering the YAML and putting timeout first in case of a flawed parse? It's particularly curious that it's rejecting timeout entirely. Even if your YAML were incorrectly indented, timeout should work either for the job or the step. Perhaps file an issue on issuetracker google.com? Meantime, you should be able to apply the timeout as a flag instead: gcloud builds submit ... --timeout=1200s ... — DazWilkin
I tried reordering to the top on a previous attempt with no success. And if you use the inline YAML option instead of the cloudbuild.yaml, it reorders it back to the bottom when you review it... but still fails even though it must have parsed the file. timeout argument isn't a valid flag for gcloud app. Unless I have to restructure the process to use gcloud builds — littleowlnest
I don't understand what you mean by "inline YAML" in your reply. I was proposing you add --timeout to gcloud builds submit (which you are using). I wonder whether the gcloud that's crashing is the one used by gcloud app deploy ... in step #2? I assumed it was the gcloud build submit ... that you're using to create the job. One thing to bear in mind (and a possible culprit) is that, because gcloud app deploy itself using Cloud Build to build your app, the issue may arise in that child build. I'm unfamiliar with Node.JS but do you need npm install and npm run build steps? — DazWilkin
Can you run gcloud app deploy ... directly without Cloud Build to deploy the app. What happens then? See the documentation for deploying Node.JS apps to App Engine: cloud.google.com/appengine/docs/standard/nodejs/… — DazWilkin
gcloud builds and gcloud app are different commands. I'm using automated builds with a trigger in Cloud Build. "Inline YAML" is an option in the Cloud Build GUI, so instead of using a cloudbuild.yaml file, the execution will use YAML that has been typed in. gcloud app deploy is definitely using the same build process as Cloud Build. — littleowlnest

littleowlnest littleowlnest · Accepted Answer · 2021-06-28T05:29:15

The timeout setting can be used if the App Engine environment is "Standard" and not "Flexible".

The environment is set by the "env" setting in app.yaml. By default if this value is not provided, the App Engine environment will be set to Standard. Simply ensure that env: flex removed from app.yaml.

It is unclear if this is by design or a bug.

Adding Timeout field causes GCloud Build to Fail, what is the correct method to increase timeout

1 Answers