Azure DevOps Конвейерная структура для PR в моно-репо - PullRequest
0 голосов
/ 27 апреля 2020

У меня есть моно-репо, содержащее несколько подпроектов (Node / TypeScript, если это имеет значение). Я пытаюсь настроить, как мне кажется, относительно простую настройку запросов на выборку в Azure DevOps, которая предназначена для развертывания PR-среды для тестирования. Он состоит из 2-х конвейеров, которые я хочу запускать один за другим в пиаре. В случае неудачи пиар также должен выйти из строя. Код находится в Azure DevOps Git.

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

  1. PR создается с тегом solution-a для объединения из От features/feature-x до dev ветвь
  2. Политика ветвления запускает solution-a-pipeline на основе тега solution-a. Другой конвейер должен быть запущен, если тег отличается.
  3. solution-a-pipeline вызывает infrastructure-pipeline и solution-a-build-pipeline в контексте features/feature-x branch * в порядке.
  4. Если solution-a-pipeline завершается успешно (косвенно это означает, что infrastructure-pipeline и solution-a-build-pipeline также успешно завершены по порядку) булид считается успешным. В противном случае произойдет сбой, и PR не будет завершен.

* Под "в контексте" я подразумеваю, что фактический файл yaml, используемый для каждого конвейера, является файлом из ветви объектов. Это потому, что я хочу, чтобы он протестировал любые изменения в конвейерах, а также любые шаги в конвейере.

Есть ли способ добиться этого? Я уже несколько дней пытаюсь использовать различные комбинации конвейерных файлов, шаблонов, ресурсов и триггеров, и я не могу обернуться вокруг этого.

Ответы [ 2 ]

1 голос
/ 28 апреля 2020

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

Мой Настройка состоит из одного большого pr-pipeline.yml файла, который запускается при проверке сборки PR в моей ветви dev. Триггер ручной, но обязательный, что позволяет лицу, выдающему PR, пометить его соответствующим образом до его начала.

После запуска конвейера самый первый шаг использует API-интерфейс Azure DevOps REST для определения присутствующих тегов. на соответствующем PR путем вызова этой конечной точки:

https://dev.azure.com/$(organizationName)/$(System.TeamProjectId)/_apis/git/repositories/$(Build.Repository.ID)/pullRequests/$(System.PullRequest.PullRequestId)/labels?api-version=5.1-preview.1

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

Для вызова конечная точка Я использую токен личного доступа (PAT), предоставленный агенту Azure DevOps в предопределенной переменной System.AccessToken и небольшим скриптом PowerShell:

$accessToken = "$(System.AccessToken)"
$basicAuth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$accessToken"))
$headers = @{Authorization = "Basic $basicAuth"}
$url = $(url)
$data = Invoke-WebRequest -Method Get -Uri $url -Headers $headers
Write-Host "##vso[task.setvariable variable=prlabels]$data"

После того, как у меня есть теги, я извлекаю каждая из них в виде отдельной переменной с использованием небольшого фрагмента PowerShell. Переменная prlabels заполняется:

$tagsJson = '$(prlabels)' | ConvertFrom-Json
$tags = $tagsJson.value | ForEach-Object { $_.name }
Write-Host "Tags: $($tags -join ";")"
$tags | ForEach-Object { Write-Host "##vso[task.setvariable variable=prlabel_$_;isOutput=true]true" }

Если мой pr помечен solution-a и solution-c, это приведет к определению следующих выходных переменных:

prlabel_solution-a = true
prlabel_solution-c = true
* 1027 Наконец, я могу использовать эти выходные переменные в качестве условий для запуска соответствующих заданий, которые выполняют фактическую сборку и развертывание для соответствующих решений. Задание, которое извлекает теги, называется PreReq, а задание, которое выводит отдельные переменные, - prlabels:
- job: DeploySolutionA
  dependsOn: PreReq
  condition: and(succeeded(), eq(dependencies.PreReq.outputs['prlabels.prlabel_solution-a'], 'true'))
  # ...

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

0 голосов
/ 28 апреля 2020

Azure DevOps Конвейерная структура для PR в моно-репо

Я мог бы понять ваши запросы, но AFAI для Azure devops, я не верю, что есть такой способ чтобы удовлетворить ваши потребности в данный момент.

Здесь есть три задачи:

  1. Мы не можем добавить тег в запрос на извлечение, вы можете проверить this нить для подробностей.

  2. Мы не можем запустить другой конвейер сборки на основе тегов. Нет такого условия для проверки правильности сборки опции.

  3. Не удалось установить порядок проверки сборки. Мы могли бы установить несколько конвейеров сборки при проверке сборки, но не могли установить их порядок. Если мы добавим проверку сборки и используем завершение сборки, чтобы установить порядок сборки, но проверка сборки будет проверять только результаты добавленного нами конвейера сборки, а не результаты других связанных конвейеров

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

Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...