Определение конвейера Azure для нескольких репозиториев

У меня есть проект в Azure, в котором много репозиториев. Все репозитории должны работать с одним и тем же конвейером, поэтому я ищу способ определить имя репозитория как переменную.

Вот пример того, чего я пытаюсь достичь:

trigger:
- master

pool:
  name: 'xxxx'

variables:
  repoName: 'repoA'

resources:
  repositories:
    - repository: repo
      type: git
      name: '50aa1c1f-21f0-4c61-8d85-d83218e705c9/$(repoName)'

steps:
- checkout: self
- checkout: repo

- script: echo Hello, world!
  displayName: 'Run a one-line script'

Есть ли у кого-нибудь идеи, как заставить это работать?

Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
Как установить LAMP Stack 1/2 на Azure Linux VM
Как установить LAMP Stack 1/2 на Azure Linux VM
В дополнение к нашему предыдущему сообщению о намерении Azure прекратить поддержку Azure Database для MySQL в качестве единого сервера после 16...
0
0
56
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

У меня есть проект в Azure, в котором много репозиториев. Все репозитории должны работать с одним и тем же конвейером, поэтому я ищу способ определить имя репозитория как переменную.

Не поддерживается использование переменной в качестве имени репозитория в ресурсе Yaml. Пожалуйста, проверьте документ ниже:

Если вы хотите получить несколько репозиториев и определить имя репо в переменной as an alternative, вы можете использовать задачу checkout.

- checkout: git://projectname/${{ variables.repoName}}@${{ variables.branchRef }}

Это упоминается в документе:

Пожалуйста, проверьте аналогичный билет для получения подробной информации.

Редактировать:

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

Вы можете использовать параметр для определения имени репо и использовать цикл each для задачи checkout.

parameters:
  - name: repoNames
    type: object
    default:
      - repo1
      - repo2
      - repo3

steps:
- checkout: self

- ${{ each repo in parameters.repoNames }}:
  - checkout: git://myproject/${{repo}}

Он проверяет все репозитории:

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

Чтобы быть более точным, нам не нужно запускать все репозитории одновременно. Это больше похоже на публикацию репозитория, он использует тот же конвейер. На самом деле, я использовал вашу идею, чтобы написать проверку следующим образом: checkout: git://myproject/${{repo}}, и она работает отлично. Большое спасибо!

Sara Halili 31.07.2024 12:17

Я хотел бы предложить другой подход:

  1. Создайте базовый конвейер в общем репозитории со всеми этапами/заданиями/шагами, используемыми всеми репозиториями/приложениями.
  2. для каждого репозитория или приложения создайте конвейер, использующий базовый конвейер (через расширяет шаблоны ).

Базовый конвейер обеспечит стандартную структуру ваших конвейеров и предотвратит дублирование кода.

Да, придется управлять несколькими конвейерами. Но с другой стороны, вам не нужно иметь сложную логику, чтобы определить, какой репозиторий/приложение используется и т. д. Также будет гораздо проще настроить пулы агентов, ресурсы, триггеры, расписания CRON для каждого из них, если необходимый.

Пример

Базовый конвейер (общий репозиторий шаблонов):

# Project: my-project
# Repository: shared-pipeline-templates
# 
# /pipelines/base-pipeline.yaml

parameters:
  # other parameters here

  - name: applicationName
    displayName: Name of the application to build and deploy
    type: string

  # As an alternative, and in case the stages are always the same for all services,
  # consider removing this parameter and hard-code the stages in the pipeline.
  - name: environments
    displayName: List of environments to deploy to
    type: object
    default: 
      - name: dev
        dependsOn: build
      - name: qa
        dependsOn: dev
      - name: prod
        dependsOn: qa

variables:
  # Common variables that are used by all repositories/applications
  - template: /pipelines/variables/common-variables.yaml

# add common resources (used by all repositories/applications) here

stages:
  - stage: Build
    dependsOn: []
    jobs:
      - job: Build
        displayName: Build
        steps:
          - script: echo Building the application
            displayName: 'Build the application'

  - ${{ each environment in parameters.environments }}:
    - stage: ${{ environment.name }}
      displayName: Deploy ${{ environment.name }}
      dependsOn: ${{ environment.dependsOn }}
      jobs:
        - deployment: Deploy${{ environment.name }}
          displayName: Build and Deploy to ${{ environment.name }}
          environment: ${{ environment.name }} # Azure DevOps environment. Use one per environment or application/environment
          variables:
            # Get the variables for the specific application and environment
            # - template: /pipelines/variables/${{ parameters.applicationName }}/${{ environment.name }}-variables.yaml
          strategy:
            runOnce:
              deploy:
                steps:
                  - script: echo Deploying to ${{ environment.name }} Environment
                    displayName: 'Deploy to ${{ environment.name }}'

Конвейер для репозитория/приложения foo:

# /pipelines/foo-pipeline.yaml

name: foo_$(Date:yyMMdd)$(Rev:rr)

# Add specific triggers, resources, cron schedules, etc for foo application here

resources:
  repositories:
    - repository: shared
      type: git
      name: my-project/shared-pipeline-templates
      ref: releases/0.1.2

extends:
  template: /pipelines/base-pipeline.yaml@shared
  parameters:
    applicationName: foo # <----------- application name can be hard-coded or use the value of a parameter
    # other parameters here

Конвейер для репозитория/приложения bar:

# /pipelines/bar-pipeline.yaml

name: bar_$(Date:yyMMdd)$(Rev:rr)

# Add specific triggers, resources, cron schedules, etc for bar application here

resources:
  repositories:
    - repository: shared
      type: git
      name: my-project/shared-pipeline-templates
      ref: releases/0.1.2

extends:
  template: /pipelines/base-pipeline.yaml@shared
  parameters:
    applicationName: bar # <----------- application name can be hard-coded or use the value of a parameter
    # other parameters here

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

Sara Halili 30.07.2024 07:42

@SaraHalili, если у вас есть десятки репозиториев для оформления заказа, вы можете использовать каждый цикл с параметром для имени репо, я обновил ответ с подробностями ниже, пожалуйста, проверьте, спасибо.

wade zhou - MSFT 30.07.2024 17:16

Другие вопросы по теме

Похожие вопросы

Перемещение видеофайла из хранилища BLOB-объектов Azure на сайт Sharepoint на C#
Не удалось создать профиль публикации функции Visual Studio 2022 Azure
Как обрабатывать несколько источников данных с учетными данными при развертывании модели AAS через конвейер выпуска Azure DevOPS
Пользовательское утверждение Azure: гость/внешний пользователь
Powershell, если функция вызывает другую функцию
Как ограничить локальный доступ к определенным конечным точкам в архитектуре распределенной виртуальной сети с помощью VPN типа «сеть-сеть»?
Получить документы/файлы с диска Share Point
Получение «System.IO.FileNotFoundException: не удалось загрузить файл или сборку Azure.Core, версия = 1.38.0.0» в приложении-функции Azure
Построитель выражений фабрики данных Azure: ошибка структурирования JSON с помощью вложенных массивов и объектов
Конвейер ci, создающий артефакт для приложения-функции, не содержит функций