0

I'm trying to use a Google Cloud Build Trigger to trigger a Cloud Build and then deploy to Cloud Run upon a Pull Request to Github repo Branch. My console looks as follows:

enter image description here

My questions:

  1. Is it possible to only trigger once the PR is approved or merged? Right now it triggers upon creation of the PR. I'd prefer to only build and deploy once my inevitable mistakes in the PR are corrected.
  2. It seems to build the feature branch I'm attempting to merge, not the main. Am I misunderstanding what Base branch means? Is that not the branch that it should build once I merge to it?

Inline YAML from the trigger:

steps:
  - name: gcr.io/cloud-builders/docker
    args:
      - build
      - '--no-cache'
      - '-t'
      - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
      - .
      - '-f'
      - Dockerfile
    id: Build
  - name: gcr.io/cloud-builders/docker
    args:
      - push
      - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
    id: Push
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:slim'
    args:
      - run
      - services
      - update
      - $_SERVICE_NAME
      - '--platform=managed'
      - '--image=$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
      - >-
        --labels=managed-by=gcp-cloud-build-deploy-cloud-run,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID,gcb-trigger-id=$_TRIGGER_ID,$_LABELS
      - '--region=$_DEPLOY_REGION'
      - '--quiet'
    id: Deploy
    entrypoint: gcloud
images:
  - '$_GCR_HOSTNAME/$PROJECT_ID/$REPO_NAME/$_SERVICE_NAME:$COMMIT_SHA'
options:
  substitutionOption: ALLOW_LOOSE
substitutions:
  _DEPLOY_REGION: europe-west1
  _LABELS: gcb-trigger-id=c764048b-0347-4f67-8a6f-93a91f4b05af
  _TRIGGER_ID: c764048b-0347-4f67-8a6f-93a91f4b05af
  _GCR_HOSTNAME: eu.gcr.io
  _PLATFORM: managed
  _SERVICE_NAME: myservice
tags:
  - gcp-cloud-build-deploy-cloud-run
  - gcp-cloud-build-deploy-cloud-run-managed
  - myservice
  • Can you check your YAML file if it's complete or its formatting is correct? Also, can you check if this documentation on [branches](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches) answer your question? – Robert G Aug 10 '22 at 05:11
  • @RobertG thanks for the tips, I missed the first "steps:" line in the yaml when pasting, but the original looks all correct to me. I think I got it right with base branch, I want to build the main, which is the base branch. – dreamwalkeranderson Aug 10 '22 at 10:01
  • my two cents: although it wasn't your intention, building PRs _before_ they merge is a very nice way to spin up quick sandboxes to allow team members to share and test changes – Patrick Michaelsen Jan 24 '23 at 10:41

2 Answers2

1
  • Make a trigger that triggers on the "Push to a branch" event
  • Set the branch to ^main$

That's pretty much it. Then whenever you merge a pull request it will trigger the build.

Travis Reeder
  • 38,611
  • 12
  • 87
  • 87
  • my source brranch is feature1 and base branch is main. Created two trigger 1. pull request to base 2. Push to branch base. As expected when pull request is created trigger 1 is run, however when pull request is merged to base branch at that time both trigger are initiated. I was expecting only trigger 2 to happen. It should not initiate trigger 1. Wondering the reason. – Neeraj Kumar Jul 27 '23 at 00:34
0

To answer your questions:

  1. Is it possible to only trigger once the PR is approved or merged? Right now it triggers upon creation of the PR. I'd prefer to only build and deploy once my inevitable mistakes in the PR are corrected.

It is possible by using manual approvals. The user must have a Cloud Build Approver role in order to update a trigger to require or not require approval, meaning the user can approve or reject builds. You can check this documentation on gate builds on approval.

2

Another option is defining an organizational policy to control which external services can invoke build triggers. You can specify any number of allowed or denied values for your organization or project. You can check this documentation on gate builds on organizational policy.

Comment control must also be set to required so that builds will only be executed after an owner or collaborator comments /gcbrun so that builds won't be automatically executed by triggers. You can check the full steps here on creating a GitHub trigger.

5

  1. It seems to build the feature branch I'm attempting to merge, not the main. Am I misunderstanding what Base branch means? Is that not the branch that it should build once I merge to it?

When you create a trigger, you will be asked to select a base branch (either main or any other branch that will be read after providing your GitHub repo). In my case, it listed two.

6

When you make changes in your repo and open a pull request, it will merge the changes from your head branch to your base branch (in this case your main).

You can check the full documentation on working with branches.

Robert G
  • 1,583
  • 3
  • 13