Я хочу, чтобы Azure Pipeline построил ветвь с таким же именем, как только что сработал запускающий конвейер.

Question

Проблема

У меня есть два репозитория A и B в одном проекте, каждый со своим конвейером A-CI и B-CI. Репо Azure Репо Git (поэтому не внешние). Я запустил конвейер B-CI, когда A-CI завершился. Если A-CI был получен при фиксации ветки develop, то B-CI запускается для сборки master, хотя B также имеет ветку develop.
Я хочу создать новую версию B для среды разработки, когда была создана новая версия dev A.

Можно ли позволить конвейеру-ресурсу запускать конвейер B-CI для построения ветви с тем же именем, что и ветка, только что построенная pipe-ресурсом? Для меня было бы хорошо, если бы он отступил до master, если соответствующая ветвь недоступна в B.

Этот сценарий работает, однако, если A-C и B-CI оба ссылаются на различные трубопроводные ямы одного и того же хранилища.

трубопроводные YAML

A-CI

trigger:
- '*'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      name: 'MyBuildPool'
    steps:
      - powershell: |
          Write-Host "Building A"

B-CI

resources:
  pipelines:
    - pipeline: Pipeline_A
      source: 'A-CI'
      trigger:
        branches:
          - master
          - develop
          - feature/*

trigger: 
- '*'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      name: MyBuildPool
    steps:
      - powershell: |
          Write-Host $(Build.SourceBranch) # is always refs/heads/master
          Write-Host $(Build.Reason) # is ResourceTrigger

Справочная информация

Основная идея заключается в том, что A содержит проект Ia C и всякий раз, когда изменяется инфраструктура проекта, тогда все приложения также должны быть развернуты.
Я не хочу помещать Ia C в репозиторий приложений, потому что у нас есть несколько приложений, поэтому мне придется разбить код Ia C на несколько частей.
И тогда у меня, вероятно, останется та же проблема, потому что некоторые ресурсы, такие как Azure KeyVault, распределяются между приложениями, поэтому A будет по-прежнему включать в себя общий материал, используемый всеми приложениями, и для его изменения потребуется повторное развертывание все приложения.

Answer 1

Проверьте конвейерные триггеры :

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

Однако, если два конвейера используют разные репозитории, тогда запущенный конвейер будет использовать последнюю версию код из ветви по умолчанию.

В этом случае, начиная с master, если ветка по умолчанию вашего B-CI, $(Build.SourceBranch) всегда refs/heads/master.

В качестве обходного пути:

Вы можете создать новый конвейер yaml для хранилища B. Вы можете использовать аналогичное содержимое файла yaml для B-CI. И вам нужно только изменить что-то в нем:

resources:
  pipelines:
    - pipeline: Pipeline_A
      source: 'A-CI'
      trigger:
        branches:
          - develop

Когда мы создаем новый файл yaml, он всегда помещается в главную ветку. Для меня я создал файл с тем же именем в ветке dev и скопировал в него тот же контент. Затем я удаляю новый файл yaml в главной ветке, теперь, когда строится конвейер dev of A-CI, будут использоваться репозитории dev of B.

Answer 2

Я думаю, что нашел хорошо работающий обходной путь, поскольку встроенные конвейерные триггеры не решают нашу конкретную проблему c (хотя я не могу сказать, есть ли у нас странный подход, и есть лучшие способы).

Что я сейчас делаю, это использую расширение 1021 * CLI DevOps на основе этой записи документации и запускаем конвейеры вручную.

трубопроводные YAML

A-CI

trigger:
- '*'

stages:
- stage: Build
  displayName: Build something and create a pipeline artifact
  jobs:
  - job: BuildJob
    pool:
      name: 'MyBuildPool'
    steps:
      - powershell: |
          Write-Host "Building A"
      # steps to publish artifact omitted

- stage: TriggerAppPipelines
  displayName: Trigger App Pipeline
  jobs:
  - job: TriggerAppPipelinesJob
    displayName: Trigger App Pipeline
    steps:
    - bash: az extension list | grep azure-devops
      displayName: 'Ensure Azure CLI DevOps extension is installed'
    - bash: |
        echo ${AZURE_DEVOPS_CLI_PAT} | az devops login
        az devops configure --defaults organization=https://dev.azure.com/MyOrg project="MyProject" --use-git-aliases true
      displayName: 'Login Azure CLI'
      env:
        AZURE_DEVOPS_CLI_PAT: $(System.AccessToken)
    # By passing the build Id of this A-CI run, I can use that in B-CI to download the matching artifact of A-CI.
    # If there is no matching branch, then the command fails. 
    - bash: |
        az pipelines run --branch $(Build.SourceBranch) --name "B-CI" --variables a_Version="$(Build.BuildId)" -o none
      displayName: 'Trigger pipeline'

B-CI

trigger: 
- '*'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      name: MyBuildPool
    steps:
      - powershell: |
          Write-Host $(Build.SourceBranch) # is same as the the triggering A-CI branch
          Write-Host $(Build.Reason) # B-CI is triggered manually but the user is Project Collection Build Service, so automated runs can be distinguished

Поскольку B-CI теперь запускается вручную, в этом нет необходимости для узла ресурса больше.