Cloud-builders: Allow for filtering of Github triggered builds

Created on 15 Jan 2019  路  4Comments  路  Source: GoogleCloudPlatform/cloud-builders

Hi,

Unfortunately, it is not possible to filter on branches when the build is triggered by Google Cloud Build for Github. Currently, every commit pushed to whatever branch automatically triggers a new build. For smaller teams, this makes little sense. We mostly do our testing locally, so we only let develop & master branches trigger builds.

We started discussing this issue here:
https://github.com/GoogleCloudPlatform/cloud-builders/issues/138. This resolved the issue for OP, but only because they were not using the GCB integration for GH.

A solution would be to simply add a branches argument of some sorts to the cloudbuild.yaml. For reference, this is how Gitlab does it:
https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified

Hope this can be resolved quickly, as the Github integration is now basically useless to us.

Most helpful comment

Right now I hacked around this limitation using a nested cloudbuilds.

The following maps _master_ branch to _production_ env and _dev_ to _staging_ env.

Would love a more native ways like others suggested (similar to Circle CI, Travis, Bitbucket Pipelines).

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    echo "Deploying and building branch $BRANCH_NAME @ $REPO_NAME... "
    case $BRANCH_NAME in
      master)
        gcloud builds submit --config=cloudbuild-deploy.yml --substitutions=_ENVIRONMENT="production",REPO_NAME="$REPO_NAME",COMMIT_SHA="$COMMIT_SHA"
        ;;
      dev)
        gcloud builds submit --config=cloudbuild-deploy.yml --substitutions=_ENVIRONMENT="staging",REPO_NAME="$REPO_NAME",COMMIT_SHA="$COMMIT_SHA"
        ;;
      *)
        echo "branch $BRANCH_NAME ignored."
    esac

All 4 comments

馃憢 When connecting GH to GCB, it isn't obvious what branches it will run on. I migrated a build from another environment that let me define which branches some steps ran on and given there were no controls I made the incorrect assumption it would only run on master. The build I just migrated does a deploy as it's final step. The first non-master branch I pushed kicked off the deploy process. Luckily I caught this happening and killed the deploy in time.

I think others are likely to make this mistake. It'd be great if there was a way to stop steps to specific conditions, maybe based off things like environment variables, given that there is already an environment variable containing the branch name, $BRANCH_NAME.

Right now I hacked around this limitation using a nested cloudbuilds.

The following maps _master_ branch to _production_ env and _dev_ to _staging_ env.

Would love a more native ways like others suggested (similar to Circle CI, Travis, Bitbucket Pipelines).

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    echo "Deploying and building branch $BRANCH_NAME @ $REPO_NAME... "
    case $BRANCH_NAME in
      master)
        gcloud builds submit --config=cloudbuild-deploy.yml --substitutions=_ENVIRONMENT="production",REPO_NAME="$REPO_NAME",COMMIT_SHA="$COMMIT_SHA"
        ;;
      dev)
        gcloud builds submit --config=cloudbuild-deploy.yml --substitutions=_ENVIRONMENT="staging",REPO_NAME="$REPO_NAME",COMMIT_SHA="$COMMIT_SHA"
        ;;
      *)
        echo "branch $BRANCH_NAME ignored."
    esac

My hack for my projects that deploy via firebase CLI is to pass the branch name as the project name and I have the master branch aliased to the projects actual name. Builds for other branches just fail at that point because the project doesn't exist.

This GitHub issue tracker is intended for bugs with the officially supported builder images specifically.
Please report issues and feature requests regarding the GCB service to our public issue tracker at
https://issuetracker.google.com/issues/new?component=190802&template=1162743

Was this page helpful?
0 / 5 - 0 ratings