[英]Google Cloud Build/Run trigger upon Pull Request on merge with specific branch
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.我正在尝试使用 Google Cloud Build Trigger 来触发 Cloud Build,然后根据对 Github repo Branch 的拉取请求部署到 Cloud Run。 My console looks as follows:
我的控制台如下所示:
My questions:我的问题:
Inline YAML from the trigger:来自触发器的内联 YAML:
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
To answer your questions:要回答您的问题:
- Is it possible to only trigger once the PR is approved or merged?
是否可以仅在 PR 被批准或合并后触发? Right now it triggers upon creation of the PR.
现在它在创建 PR 时触发。 I'd prefer to only build and deploy once my inevitable mistakes in the PR are corrected.
我宁愿只在 PR 中不可避免的错误得到纠正后才构建和部署。
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.用户必须具有
Cloud Build Approver
角色才能将触发器更新为需要或不需要批准,这意味着用户可以批准或拒绝构建。 You can check this documentation on gate builds on approval .您可以在批准的基础上查看此文档。
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.还必须将注释控制设置为
required
,以便仅在所有者或协作者注释/gcbrun
后执行构建,从而触发器不会自动执行构建。 You can check the full steps here on creating a GitHub trigger .您可以在此处查看有关创建 GitHub 触发器的完整步骤。
- It seems to build the feature branch I'm attempting to merge, not the main.
它似乎构建了我试图合并的功能分支,而不是主分支。 Am I misunderstanding what Base branch means?
我是否误解了 Base 分支的含义? 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).当您创建触发器时,系统会要求您 select 一个基本分支(在提供 GitHub 存储库后将读取的主分支或任何其他分支)。 In my case, it listed two.
就我而言,它列出了两个。
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 ).当您在 repo 中进行更改并打开拉取请求时,它会将更改从您的head 分支合并到您的base 分支(在本例中为您的main )。
You can check the full documentation on working with branches .您可以查看有关使用分支的完整文档。
^main$
^main$
That's pretty much it.差不多就是这样。 Then whenever you merge a pull request it will trigger the build.
然后,每当您合并拉取请求时,它都会触发构建。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.