Условный шаг сборки Google Cloud

Это мой файл сборки облака

substitutions:
    _CLOUDSDK_COMPUTE_ZONE: us-central1-a 
    _CLOUDSDK_CONTAINER_CLUSTER: $_CLOUDSDK_CONTAINER_CLUSTER
steps:
- name: gcr.io/$PROJECT_ID/sonar-scanner:latest
  args:
    - '-Dsonar.host.url=https://sonar.test.io'
    - '-Dsonar.login=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
    - '-Dsonar.projectKey=test-service'
    - '-Dsonar.sources=.'
- id: 'build test-service image'
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA', '.']
- id: 'push test-service image'
  name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA']
- id: 'set test-service image in yamls'
  name: 'ubuntu'
  args: ['bash','-c','sed -i "s,TEST_SERVICE,gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA," k8s/*.yaml']
- id: kubectl-apply
  name: 'gcr.io/cloud-builders/kubectl'
  args: ['apply', '-f', 'k8s/']
  env:
  - 'CLOUDSDK_COMPUTE_ZONE=${_CLOUDSDK_COMPUTE_ZONE}'
  - 'CLOUDSDK_CONTAINER_CLUSTER=${_CLOUDSDK_CONTAINER_CLUSTER}'
images: ['gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA']

я хотел бы реализовать шаг условия. Где моя ступенька эхолота.

Если ветка является производственной, мне нужно пропустить шаг сонара, а если есть другие ветки, нужно запустить шаг.

Я хочу управлять одним и тем же Cloudbuild.yaml во всех филиалах.

как сливаю ветки development > staging > production.

Так возможно ли с облачной сборкой реализовать условный шаг?


person Harsh Manvar    schedule 04.10.2019    source источник


Ответы (2)


У вас есть 2 решения

  1. Сделайте 2 триггера, каждый со своей конфигурацией. 1 на Prod, 1 на UAT / DEV.
  2. Вы можете написать сценарий своего исполнения. Он грязный, но у вас остается только 1 файл конфигурации CI / CD
steps:
- name: gcr.io/$PROJECT_ID/sonar-scanner:latest
  entrypoint: 'bash'
  args:
    - '-c'
    - 'if [ $BRANCH_NAME != 'prod' ]; then sonar-scanner -Dsonar.host.url=https://sonar.test.io -Dsonar.login=XXXX -Dsonar.projectKey=test-service -Dsonar.sources=. ; fi'
person guillaume blaquiere    schedule 04.10.2019
comment
спасибо за то, что написали ответ. Не могли бы вы подробнее рассказать об этом <exec in your container, mvn?>. не получил. Я должен изменить стоимость там или просто оставить как есть. - person Harsh Manvar; 04.10.2019
comment
Конечно, вы создали собственный конструктор облаков. В конце этого контейнера, последней строке, вы пишете ENTRYPOINT ‹something›. Это то же самое «что-то» и положить туда. Я думаю, это sonar-scanner (это есть в документации sonarQube) - person guillaume blaquiere; 04.10.2019
comment
Спасибо за ответ, я попробую еще раз спасибо. - person Harsh Manvar; 05.10.2019

Невозможно (пока) создавать условные шаги в сборке облака, как это возможно, например, с помощью gitlab-ci. Мы создали несколько проектов в GCP. Вы можете создать проект для разработки, постановки и производства. Все они взяты из одного репозитория git, чтобы среды оставались идентичными друг другу. Это означает, что у них один и тот же файл cloudbuild.yaml.

Если вам каким-то образом нужно запустить конкретный сценарий только в среде разработки, например, сквозной тест, вы должны указать условие для $ BRANCH_NAME или $ PROJECT_ID на самом этапе сборки. Однако чрезмерное использование этих условных обозначений повредит ремонтопригодности, и ваша среда не будет точным зеркалом друг друга. Тем не менее, вот простой пример:

---
timeout: 300s
steps:
  # Branch name conditional
  - name: gcr.io/google.com/cloudsdktool/cloud-sdk
    entrypoint: bash
    args:
      - -c
      - |
        if [[ "$BRANCH_NAME" == "develop" ]]
        then
          echo "Development stuff only"
        elif [[ "$BRANCH_NAME" == "release" ]]
        then
          echo "Acceptance stuff only"
        elif [[ "$BRANCH_NAME" == "main" ]]
        then
          echo "Production stuff only"
        fi

Помимо создания разных проектов для каждой среды, я также рекомендовал бы создавать проект для каждого домена или приложения. Это означает, что у вас есть логическое разделение данных, хранящихся в проектах. Затем вы можете сгруппировать все проекты разработки в папку под названием разработка и т. Д. Эти папки являются частью организации или даже другой папки.

Эта логическая группировка - одно из реальных преимуществ использования GCP, я считаю ее очень удобной. В Azure есть несколько схожая структура с группами ресурсов и подписками. AWS также имеет структуру группы ресурсов.

person Nebulastic    schedule 19.06.2020
comment
Спасибо, что нашли время и написали ответ. у той же работы был другой проект с триггером облачной сборки в соответствующих ветвях. - person Harsh Manvar; 19.06.2020