Deploy a workflow from a Git repository using Cloud Build

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

  1. Enable the Cloud Build and Workflows APIs.

    Enable the APIs

  2. Grant theWorkflows Admin role(roles/workflows.admin) to the Cloud Build service account:

    1. In the Google Cloud console, go to theIAM page.

      Go to IAM

    2. Select your project.

    3. In the row for the Cloud Build service account(PROJECT_NUMBER@cloudbuild.gserviceaccount.com),clickEdit principal.

    4. ClickAdd another role.

    5. In theRole list, select theWorkflows Adminrole.

    6. ClickSave.

  3. Grant theService Account User role(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.

    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.
    1. In the Google Cloud console, go to theService Accounts page.

      Go to Service Accounts

    2. Select your project.

    3. Click the email address of the Compute Engine default service account(PROJECT_NUMBER-compute@developer.gserviceaccount.com).

    4. Click thePermissions tab.

    5. Click theGrantaccess button.

    6. To add a new principal, enter the email address of your service account(SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com).

    7. In theSelect a role list, select theService Accounts>Service Account User role.

    8. ClickSave.

gcloud

  1. Enable the Cloud Build and Workflows APIs.

    gcloudservicesenablecloudbuild.googleapis.com\workflows.googleapis.com
  2. Grant 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.admin

    ReplacePROJECT_ID with the ID of your Google Cloudproject.

  3. Grant theService Account User role(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.

    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.
    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:

  1. In the Google Cloud console, go to the Cloud BuildTriggerspage:

    Go to Triggers

  2. If necessary, select your project and clickOpen.

  3. 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.
  4. ClickConnect repository.

  5. Select the source repository where you've stored your source code.

    For example:GitHub (Cloud Build GitHub App)

  6. ClickContinue.

  7. 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.

  8. 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.

  9. Read the disclaimer and select the checkbox next to it to indicate that youconsent to the terms.

  10. ClickConnect.

  11. 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:

  1. In the Google Cloud console, go to the Cloud BuildTriggers page:

    Go to Triggers

  2. ClickCreate trigger.

  3. In theName field, enter a name for your trigger.

  4. ForEvent, select the event to invoke your trigger.

    For example:Push to a branch

  5. 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 themain andstaging branches)

  6. 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.yaml

  7. ForConfiguration, selectCloud Buildconfiguration file (YAML or JSON) as the type, andRepository as thelocation.

  8. In theCloud Build configuration file location field,specify the location of your file.

    For example:gitops/cloudbuild.yaml

  9. Optionally, to add a substitution variable, clickAdd variable andspecify a key and value combination.

    For example:_WORKFLOW_NAME (variable) andworkflows-gitops (value)

  10. 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.

  1. In thestaging branch of the Git repository, editworkflow.yaml, andchangeHello World toBye World:

    main:steps:-init:assign:-message:"HelloWorld"-returnResult:return:${message}
  2. Commit and push the change to thestaging branch.

    gitaddworkflow.yamlgitcommit-m"Update workflow.yaml in staging"gitpush

    The Cloud Build trigger runs and initiates a build.

  3. To confirm the success of the build, in the Google Cloud console, go totheBuild history page:

    Go to Build history

    After a build completes, Cloud Build provides an overall statusfor the build and for each individual build step. For more information, seeView build results.

  4. To confirm that a staging workflow is deployed, in the Google Cloud console,go to theWorkflows page:

    Go to Workflows

    You should see a workflow namedworkflows-gitops-staging listed.

  5. To deploy the staging workflow to production, merge thestaging branch tothemain branch:

    gitcheckoutmaingitmergestaginggitpush

    Note that becausetest-main.sh is expectingHello World in 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;fi
  6. To successfully deploy a production workflow, in thestaging branch, editworkflow.yaml again and change the string back toHello World.

  7. Commit and push the change to thestaging branch and then merge thestaging branch to themain branch.

  8. To confirm that a production workflow is deployed, in the Google Cloud console,go to theWorkflows page:

    Go to Workflows

    You should see a workflow namedworkflows-gitops-main listed.

What's next

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.