2

我有一个包含不同云功能文件夹的项目文件夹，例如

Project_Folder
    -Cloud-Function-Folder1
         -main.py
         -requirements.txt
         -cloudbuild.yaml
    -Cloud-Function-Folder2
         -main.py
         -requirements.txt
         -cloudbuild.yaml
    -Cloud-Function-Folder3
         -main.py
         -requirements.txt
         -cloudbuild.yaml
            --------- and so on!

现在我现在拥有的是。我将代码从 Cloud Fucntions 文件夹一一推送到 Source Repository 到 Source Repository（每个函数文件夹单独的 Repos）。然后它启用了触发云构建然后部署功能的触发器。我拥有的 cloudbuild.yaml 文件如下所示。

 steps:

 - name: 'python:3.7'
 entrypoint: 'bash'
 args: 
   - '-c'
   - |
       pip3 install -r requirements.txt
       pytest

 - name: 'gcr.io/cloud-builders/gcloud'
  args:
  - functions 
  - deploy
  - Function
  - --runtime=python37
  - --source=.
  - --entry-point=function_main
  - --trigger-topic=Function
  - --region=europe-west3

现在，我想做的是我想做一个单一的源代码库，每当我更改一个云函数中的代码并推送它时，只有它得到部署，其余的仍然像以前一样。

更新

现在我也在下面尝试了类似的方法，但它也同时部署了所有功能，即使我正在处理一个功能。

Project_Folder
    -Cloud-Function-Folder1
         -main.py
         -requirements.txt
    -Cloud-Function-Folder2
         -main.py
         -requirements.txt
    -Cloud-Function-Folder3
         -main.py
         -requirements.txt
    -cloudbuild.yaml
    -requirements.txt

cloudbuild.yaml 文件如下所示

 steps:

 - name: 'python:3.7'
 entrypoint: 'bash'
 args: 
   - '-c'
   - |
       pip3 install -r requirements.txt
       pytest

 - name: 'gcr.io/cloud-builders/gcloud'
  args:
  - functions 
  - deploy
  - Function1
  - --runtime=python37
  - --source=./Cloud-Function-Folder1
  - --entry-point=function1_main
  - --trigger-topic=Function1
  - --region=europe-west3  

 - name: 'gcr.io/cloud-builders/gcloud'
  args:
  - functions 
  - deploy
  - Function2
  - --runtime=python37
  - --source=./Cloud-Function-Folder2
  - --entry-point=function2_main
  - --trigger-topic=Function2
  - --region=europe-west3
4

3 回答 3

1

它更复杂，您必须使用 Cloud Build 的限制和约束。

我这样做：

  • 获取自上次提交以来更新的目录
  • 在这个目录上循环并做我想做的事

假设1：所有子文件夹都使用相同的命令部署

因此，为此，我将 acloudbuild.yaml放在目录的根目录中，而不是在子文件夹中

steps:
- name: 'gcr.io/cloud-builders/git'
  entrypoint: /bin/bash
  args:
    - -c
    - |
        # Cloud Build doesn't recover the .git file. Thus checkout the repo for this
        git clone --branch $BRANCH_NAME https://github.com/guillaumeblaquiere/cloudbuildtest.git /tmp/repo ;
        # Copy only the .git file
        mv /tmp/repo/.git .
        # Make a diff between this version and the previous one and store the result into a file
        git diff --name-only --diff-filter=AMDR @~..@ | grep "/" | cut -d"/" -f1 | uniq > /workspace/diff

# Do what you want, by performing a loop in to the directory
- name: 'python:3.7'
  entrypoint: /bin/bash
  args:
    - -c
    - |
       for i in $$(cat /workspace/diff); do
       cd $$i
           # No strong isolation between each function, take care of conflicts!!
           pip3 install -r requirements.txt
           pytest
       cd ..
       done

- name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: /bin/bash
  args:
    - -c
    - |
       for i in $$(cat /workspace/diff); do
       cd $$i
           gcloud functions deploy .........           
       cd ..
       done

假设 2：部署特定于子文件夹

所以，为此我把一个cloudbuild.yaml放在我的目录的根目录下，另一个放在子文件夹中

steps:
- name: 'gcr.io/cloud-builders/git'
  entrypoint: /bin/bash
  args:
    - -c
    - |
        # Cloud Build doesn't recover the .git file. Thus checkout the repo for this
        git clone --branch $BRANCH_NAME https://github.com/guillaumeblaquiere/cloudbuildtest.git /tmp/repo ;
        # Copy only the .git file
        mv /tmp/repo/.git .
        # Make a diff between this version and the previous one and store the result into a file
        git diff --name-only --diff-filter=AMDR @~..@ | grep "/" | cut -d"/" -f1 | uniq > /workspace/diff

# Do what you want, by performing a loop in to the directory. Here launch a cloud build
- name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: /bin/bash
  args:
    - -c
    - |
       for i in $$(cat /workspace/diff); do
       cd $$i
           gcloud builds submit
       cd ..
       done

注意这里的超时，因为你可以触发大量的 Cloud Build 并且需要一些时间。

想要手动运行您的构建，不要忘记添加 $BRANCH_NAME 作为替换变量

gcloud builds submit --substitutions=BRANCH_NAME=master
于 2020-03-06T11:15:35.600 回答
0

这很简单，但是您需要在构建触发器端控制行为，而不是在cloudbuild.yaml. 从概念上讲，您希望限制云构建触发行为并将其限制为存储库中的某些更改。

因此，在 Build Trigger 页面中使用 regEx glob include 过滤器：

GCP 触发器上的输入文件 glob 过滤器的屏幕截图

您将为每个云功能（或云运行）构建一个触发器，并按如下方式设置“包含的文件过滤器（glob）”：

  • Cloud-Function1-Trigger

    Project_Folder/Cloud-Function-Folder1/**

  • Cloud-Function2-Trigger

    Project_Folder/Cloud-Function-Folder2/**

...

假设：

  1. 对于每个触发器，设置 repo 和分支，以便 repo 的根具有 Project_Folder/
  2. Repo 和分支被适当地设置为，以便触发器可以定位和访问路径 Project_Folder/Cloud-Function-Folder1/* 中的文件

当我拥有超过 2-3 个云功能时，我倾向于使用 Terraform 以自动化方式创建所有必需的触发器。

于 2021-07-01T06:26:32.697 回答
-3

如果您创建单个源代码库并将代码更改为一个云功能，则必须创建一个“cloudbuild.yaml”配置文件。您需要将此单一存储库连接到 Cloud Build。然后创建一个构建触发器，选择这个 repo 作为 Source。此外，您需要配置部署，并且每当您将新代码推送到存储库时，您将自动触发构建并在 Cloud Functions 上部署。

于 2020-03-06T09:48:03.993 回答