Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for filtering of Github triggered builds #431

Closed
DiederikvandenB opened this issue Jan 15, 2019 · 4 comments

Comments

@DiederikvandenB
Copy link

commented Jan 15, 2019

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

@leighmcculloch

This comment has been minimized.

Copy link

commented Jan 16, 2019

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

@williamli

This comment has been minimized.

Copy link

commented Jan 18, 2019

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
@leighmcculloch

This comment has been minimized.

Copy link

commented Jan 19, 2019

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.

@bendory

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

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

@bendory bendory closed this Jun 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.