Deploy a workflow from a Git repository using Cloud Build Stay organized with collections Save and categorize content based on your preferences.
You can use a Cloud Build trigger to automatically start a buildand deploy a workflow from a Git repository. You can configure the trigger todeploy your workflow on any change to the source repository, or deploy theworkflow only when the change matches specific criteria.
This approach can help you manage your deployment lifecycle. For example, youcan deploy changes to a workflow in a staging environment, run tests againstthat environment, and then incrementally roll out these changes to theproduction environment.
Before you begin
These instructions assume you have theCloud Build Editor role(roles/cloudbuild.builds.editor) in your Google Cloud project so that youcan create triggers. You also need a workflow in a source repository such asGitHub or Bitbucket.
Console
Enable the Cloud Build and Workflows APIs.
Grant theWorkflows Admin role(
roles/workflows.admin) to the Cloud Build service account:In the Google Cloud console, go to theIAM page.
Select your project.
In the row for the Cloud Build service account(
PROJECT_NUMBER@cloudbuild.gserviceaccount.com),clickEdit principal.ClickAdd another role.
In theRole list, select theWorkflows Adminrole.
ClickSave.
Grant theService Account User role(
Caution: Assigning theService Account User roleindirectly grants the role associated with the default service account tothe user. For example, if the default service account has the Editor role,the user can then "act as" an Editor. To minimize the impact of these roleassignments, we recommend configuring the default service accountaccording tothe principle of least privilege.For more information, seeDisable automatic role grants to default service accounts.roles/iam.serviceAccountUser) on the Compute Engine default serviceaccount to the Cloud Build service account. When you haveenabled the Compute Engine API,the Compute Engine default service account isPROJECT_NUMBER-compute@developer.gserviceaccount.com.In the Google Cloud console, go to theService Accounts page.
Select your project.
Click the email address of the Compute Engine default service account(
PROJECT_NUMBER-compute@developer.gserviceaccount.com).Click thePermissions tab.
Click theGrantaccess button.
To add a new principal, enter the email address of your service account(
SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com).In theSelect a role list, select theService Accounts>Service Account User role.
ClickSave.
gcloud
Enable the Cloud Build and Workflows APIs.
gcloudservicesenablecloudbuild.googleapis.com\workflows.googleapis.comGrant theWorkflows Admin role(
roles/workflows.admin) to the Cloud Build service account:PROJECT_NUMBER=$(gcloudprojectsdescribePROJECT_ID--format='value(projectNumber)')gcloudprojectsadd-iam-policy-bindingPROJECT_ID\--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com\--role=roles/workflows.adminReplace
PROJECT_IDwith the ID of your Google Cloudproject.Grant theService Account User role(
Caution: Assigning theService Account User roleindirectly grants the role associated with the default service account tothe user. For example, if the default service account has the Editor role,the user can then "act as" an Editor. To minimize the impact of these roleassignments, we recommend configuring the default service accountaccording tothe principle of least privilege.For more information, seeDisable automatic role grants to default service accounts.roles/iam.serviceAccountUser) on the Compute Engine default serviceaccount to the Cloud Build service account. When you haveenabled the Compute Engine API,the Compute Engine default service account isPROJECT_NUMBER-compute@developer.gserviceaccount.com.gcloudiamservice-accountsadd-iam-policy-binding\$PROJECT_NUMBER-compute@developer.gserviceaccount.com\--member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com\--role=roles/iam.serviceAccountUser
Connect to your source repository
You must connect Cloud Build to your source repository so thatCloud Build can automate builds in response to events that happenin the repository.
Complete the following steps to connect to GitHub or Bitbucket:
In the Google Cloud console, go to the Cloud BuildTriggerspage:
If necessary, select your project and clickOpen.
From theRegion list, select the region where you would like to createyour trigger.
Note: If you selectglobal as your region, default pools are used to runyour build; otherwise, aprivate pool in theregion of your trigger is used. Youmust specify the private pool in yourbuild config file or through build arguments.ClickConnect repository.
Select the source repository where you've stored your source code.
For example:GitHub (Cloud Build GitHub App)
ClickContinue.
Authenticate to your source repository with your username and password.
If you are signing into GitHub, you are asked to authorise the GoogleCloud Build GitHub App to access your GitHub account to proceed.
From the list of available repositories, select the desired repository, andthen clickOK.
For external repositories such as GitHub and Bitbucket, you must haveowner-level permissions for the Google Cloud project in which you'reworking.
Read the disclaimer and select the checkbox next to it to indicate that youconsent to the terms.
ClickConnect.
To continue creating a build trigger to automate builds for the source codein the repository, clickCreate a trigger. Otherwise, clickDone.
Create a Cloud Build configuration file
A build configuration file defines the fields that are needed when using abuild trigger to start a build. Create the config file in your project rootdirectory and write it using either YAML or JSON.
For example, the following config file deploys and runs a test workflow, andthen uses a script to check the output. If the test passes, the workflow isdeployed:
steps:# Deploy the test workflow with the commit sha-id:'deploy-test-workflow'name:'gcr.io/cloud-builders/gcloud'args:['workflows','deploy','$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA','--source','gitops/workflow.yaml']# Run the test workflow and capture the output-id:'run-test-workflow'name:'gcr.io/cloud-builders/gcloud'entrypoint:'bash'args:['-c','gcloudworkflowsrun$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA >/workspace/testoutput.log']# Delete the test workflow-id:'delete-test-workflow'name:'gcr.io/cloud-builders/gcloud'args:['workflows','delete','$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA','--quiet']# Check the test output-id:'check-test-workflow'name:'gcr.io/cloud-builders/gcloud'entrypoint:'bash'args:['gitops/test-$BRANCH_NAME.sh']# Deploy the workflow-id:'deploy-workflow'name:'gcr.io/cloud-builders/gcloud'args:['workflows','deploy','$_WORKFLOW_NAME-$BRANCH_NAME','--source','gitops/workflow.yaml']The$BRANCH_NAME and$SHORT_SHAsubstitution variablesare populated by Cloud Build when a build is triggered from a Gitrepository. They represent the name of your branch, and the first sevencharacters of the commit ID associated with your build, respectively.
The$_WORKFLOW_NAME substitution variable allows you to re-use a config filewith different variable values. You can specify its value when you create thebuild trigger.
For more information, seeCreate a build configuration file.
Create a build trigger
You can automate the deployment of your workflow by creating aCloud Build trigger.
To create a build trigger for the config file in the previous section:
In the Google Cloud console, go to the Cloud BuildTriggers page:
ClickCreate trigger.
In theName field, enter a name for your trigger.
ForEvent, select the event to invoke your trigger.
For example:Push to a branch
ForSource, select your repository, and the branch or tag namethat will start your trigger. You can use a regular expression to specify amatch to a branch or tag.
For example:
GoogleCloudPlatform/workflows-demos(repository) and^main$|^staging$(matches themainandstagingbranches)Expand theShow included and ignored files filters section and specifyyour workflow as an included file so that when it is changed, a build is invoked.
For example:
gitops/workflow.yamlForConfiguration, selectCloud Buildconfiguration file (YAML or JSON) as the type, andRepository as thelocation.
In theCloud Build configuration file location field,specify the location of your file.
For example:
gitops/cloudbuild.yamlOptionally, to add a substitution variable, clickAdd variable andspecify a key and value combination.
For example:
_WORKFLOW_NAME(variable) andworkflows-gitops(value)To save your build trigger, clickCreate.
When any changes are pushed to a workflow in the specified branch of the Gitrepository, it will automatically trigger Cloud Build to deploy theworkflow.
For more information, seeCreate and manage build triggers.
Test the build trigger
You can test the build trigger and config file from the previous sections.
In the
stagingbranch of the Git repository, editworkflow.yaml, andchangeHello WorldtoBye World:main:steps:-init:assign:-message:"HelloWorld"-returnResult:return:${message}Commit and push the change to the
stagingbranch.gitaddworkflow.yamlgitcommit-m"Update workflow.yaml in staging"gitpushThe Cloud Build trigger runs and initiates a build.
To confirm the success of the build, in the Google Cloud console, go totheBuild history page:
After a build completes, Cloud Build provides an overall statusfor the build and for each individual build step. For more information, seeView build results.
To confirm that a staging workflow is deployed, in the Google Cloud console,go to theWorkflows page:
You should see a workflow named
workflows-gitops-staginglisted.To deploy the staging workflow to production, merge the
stagingbranch tothemainbranch:gitcheckoutmaingitmergestaginggitpushNote that because
test-main.shis expectingHello Worldin the output ofthe workflow, the build will fail:RESULT_EXPECTED="result: '\"Hello World\"'"RESULT_ACTUAL=$(grep"result: "$FILE)if[[$RESULT_EXPECTED==$RESULT_ACTUAL]];thenecho"Result test passed"elseecho"Result test failed. Expected:$RESULT_EXPECTED Actual:$RESULT_ACTUAL";exit1;fiTo successfully deploy a production workflow, in the
stagingbranch, editworkflow.yamlagain and change the string back toHello World.Commit and push the change to the
stagingbranch and then merge thestagingbranch to themainbranch.To confirm that a production workflow is deployed, in the Google Cloud console,go to theWorkflows page:
You should see a workflow named
workflows-gitops-mainlisted.
What's next
- Learn more aboutCloud Build.
- Learn how totroubleshoot build errors.
- Learn how totroubleshoot Workflows.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-02-19 UTC.