Конвейер Azure Devops с дополнительным этапом, запускаемым вручную

Я использую конвейеры Azure DevOps YAML и имею два этапа: один — развертывание в разработке (запускается при фиксации в мастере), а второй — проверка запросов на извлечение (выполнение тестов и статический анализ).

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

• Тестовый конвейер: запускает тесты и статический анализ.
• Развертывание конвейера: развертывает код.

После разделения конвейеров создайте политику сборки в разделе Build Validation для каждого из них:

• Политика тестового конвейера должна быть настроена по мере необходимости, т. е. сборка всегда должна выполняться как часть проверки запроса на включение.
• Политика конвейера развертывания должна быть установлена ​​как необязательная: создатель PR должен решить, следует ли запускать эту сборку как часть проверки запроса на включение или нет.

Пример политики для конвейера развертывания:

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

trigger:
- master

pool:
  vmImage: ubuntu-latest

stages:
- stage: stage1
  condition: and(
                eq(variables['Build.Reason'], 'IndividualCI'),
                eq(variables['Build.SourceBranchName'], 'master')
              ) 
  jobs:
  - job: DeployToDevUponCI
    steps:
    - pwsh: |
        Write-Host "This is stage 1 deploying to Dev upon CI trigger"

- stage: stage2
  dependsOn: []
  condition: eq(variables['Build.Reason'], 'PullRequest')
  jobs:
  - job: Tests
    steps:
    - pwsh: |
        Write-Host "This is stage 2 running tests upon PR validation trigger"
        Write-Host "##vso[build.addbuildtag]stage2succeeded" # Add Build tag to filter the latest artifacts for download during stage3
    - publish: $(System.DefaultWorkingDirectory)
      artifact: drop$(Build.BuildId)

- stage: stage3
  dependsOn: stage2
  variables:
  - group: VG-DeployDevUponPR
  condition: eq(variables['DeployDevUponPR'], 'True')
  jobs:
  - job: DeployToDevUponPR
    steps:
    - task: DownloadPipelineArtifact@2
      inputs:
        buildType: 'specific'
        project: 'TheProjectName'
        definition: 'DeployDevUponPR'
        buildVersionToDownload: 'latest'
        tags: 'stage2succeeded'
        targetPath: '$(Pipeline.Workspace)'
    - pwsh: |
        Write-Host "This is stage 3 deploying to Dev upon CI trigger"
        tree $(Pipeline.Workspace)
        Write-Host "DeployDevUponPR - $(DeployDevUponPR)"
        Write-Host "After deployment - Reset the variable DeployDevUponPR in variable group 36 as false"
        az pipelines variable-group variable update --group-id 36 `
          --name DeployDevUponPR `
          --org $(System.CollectionUri) `
          --project $(System.TeamProject) `
          --value False
      env: 
        AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
      displayName: Reset the variable DeployDevUponPR in variable group 36 as false
      condition: always()

   

Когда конвейер запускался PR, stage3 всегда пропускался, пока вы вручную не установили значение переменной в группе переменных как True. Статус сборки проверки PR также был успешным. А когда вы захотите развернуть stage3, вы можете создать новый запуск только с выбранным stage3, который не будет отображаться на странице PR. Вы также можете использовать сценарий CLI Azure DevOps для обновления всех необходимых переменных среды в группе переменных во время stage2 для использования stage3.

Кстати, Build.Reason для развертывания новой сборки stage3Manual не PullRequest. Если вам подходит временное хранение переменных среды в группе переменных, это также должно работать в отдельных конвейерах.