Reputation: 55
I'm deploying to Kubernettes via Cloud Build. Every now and then the build times out because it exceeds the build-in time out of ten minutes. I can't figure out how to increase this time out. I'm using in-line build config in my trigger. It looks like this
steps:
- name: gcr.io/cloud-builders/docker
args:
- build
- '-t'
- '$_IMAGE_NAME:$COMMIT_SHA'
- .
- '-f'
- $_DOCKERFILE_NAME
dir: $_DOCKERFILE_DIR
id: Build
- name: gcr.io/cloud-builders/docker
args:
- push
- '$_IMAGE_NAME:$COMMIT_SHA'
id: Push
- name: gcr.io/cloud-builders/gke-deploy
args:
- prepare
- '--filename=$_K8S_YAML_PATH'
- '--image=$_IMAGE_NAME:$COMMIT_SHA'
- '--app=$_K8S_APP_NAME'
- '--version=$COMMIT_SHA'
- '--namespace=$_K8S_NAMESPACE'
- '--label=$_K8S_LABELS'
- '--annotation=$_K8S_ANNOTATIONS,gcb-build-id=$BUILD_ID'
- '--create-application-cr'
- >-
--links="Build
details=https://console.cloud.google.com/cloud-build/builds/$BUILD_ID?project=$PROJECT_ID"
- '--output=output'
id: Prepare deploy
- name: gcr.io/cloud-builders/gsutil
args:
- '-c'
- |-
if [ "$_OUTPUT_BUCKET_PATH" != "" ]
then
gsutil cp -r output/suggested gs://$_OUTPUT_BUCKET_PATH/config/$_K8S_APP_NAME/$BUILD_ID/suggested
gsutil cp -r output/expanded gs://$_OUTPUT_BUCKET_PATH/config/$_K8S_APP_NAME/$BUILD_ID/expanded
fi
id: Save configs
entrypoint: sh
- name: gcr.io/cloud-builders/gke-deploy
args:
- apply
- '--filename=output/expanded'
- '--cluster=$_GKE_CLUSTER'
- '--location=$_GKE_LOCATION'
- '--namespace=$_K8S_NAMESPACE'
id: Apply deploy
timeout: 900s
images:
- '$_IMAGE_NAME:$COMMIT_SHA'
options:
substitutionOption: ALLOW_LOOSE
substitutions:
_K8S_NAMESPACE: default
_OUTPUT_BUCKET_PATH: xxxxx-xxxxx-xxxxx_cloudbuild/deploy
_K8S_YAML_PATH: kubernetes/
_DOCKERFILE_DIR: ''
_IMAGE_NAME: xxxxxxxxxxx
_K8S_ANNOTATIONS: gcb-trigger-id=xxxxxxxx-xxxxxxx
_GKE_CLUSTER: xxxxx
_K8S_APP_NAME: xxxxx
_DOCKERFILE_NAME: Dockerfile
_K8S_LABELS: ''
_GKE_LOCATION: xxxxxxxx
tags:
- gcp-cloud-build-deploy
- $_K8S_APP_NAME
I've tried sticking the timeout: 900
arg in in various places with no luck.
Upvotes: 1
Views: 535
Reputation: 7286
Another way to solve this problem is to use a high-end machine so that overall it takes less time in the build process.
You can specify it like
options:
machineType: N1_HIGHCPU_8
Note: This performance benefits come at a cost. Please look into the pricing section to use optimal machine as per your requirement and budget.
Upvotes: 0
Reputation: 2683
The timeout of 10 minutes is the default for the whole build, therefore if you add the timeout: 900s
option in any of the steps, it will only apply to the step that it has been added to. You can make a step have a larger timeout than the overall build timeout, but the whole build process will fail if the sum of all the steps exceeds the build timeout. This example shows this behavior:
steps:
- name: 'ubuntu'
args: ['sleep', '600']
timeout: 800s # Step timeout -> Allows the step to run up to 800s, but as the overall timeout is 600s, it will fail after that time has been passed, so the effective timeout value is 600s.
timeout: 600s # Overall build timeout
That said, the solution is to expand the overall build timeout by adding it outside of any step, and then you can have a build with up to 24h to finish before it fails with a timeout error.
Something like the following example should work out for you:
steps:
- name: 'ubuntu'
args: ['sleep', '600']
timeout: 3600s
Upvotes: 2