политики филиала Azure репо

Я потратил полдень, приводя в порядок несколько репозиториев в лазурном DevOps. Все идет хорошо.

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

{новые функции} - ›nightly-› test- ›master

В настоящее время это делается вручную, и есть рассказы об усталых разработчиках в пятницу днем, которые спешат, сводят поток и убивают производство (основная ветка)

Я ввел ряд политик, например количество рецензентов и проверку путем запуска модульных тестов.

Вопрос в том, могу ли я с помощью репозиториев Azure ограничить, какую ветвь можно связать с PR в другую и как?


person user3067684    schedule 26.06.2020    source источник


Ответы (3)


Проект ›› Настройки ›› Репозитории ›› Выбрать репо ›› Политики ›› Выбрать ветку

Вы не можете контролировать, можно ли его рекламировать, только те обручи, через которые люди должны прыгнуть, прежде чем его можно будет одобрить и / или объединить.

  • Минимум # рецензентов
  • Проверить наличие связанных рабочих элементов
  • Проверить разрешение комментария
  • Ограничить типы слияния. Может быть, включите это и снимите флажки все, чтобы после утверждения PR его нельзя было объединить?
person Bill Jetzer    schedule 26.06.2020

Вопрос в том, могу ли я с помощью репозиториев Azure ограничить, какую ветку можно связать с PR в другую и как?

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

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

В качестве теста я создал встроенную задачу PowerShell, чтобы ограничить, в какую ветку можно добавить PR:

$branch = $Env:System_PullRequest_SourceBranch
Write-Host "Current branch is $branch"
if ($branch -eq "refs/heads/Dev1")
{
  Write-Host ("The source branch is expected branch.")
}
elseif ($branch -ne "refs/heads/Dev1")
{
  Write-Host ("##vso[task.complete result=Failed;]DONE")
}

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

person Leo Liu-MSFT    schedule 29.06.2020
comment
Спасибо за это Leo Liu-MSFT. Мое решение состояло в том, чтобы использовать jobs- ›job в конвейере yaml с условием, смотрящим на исходную ветвь. `` `условие: eq (variables ['Build.SourceBranch'], variables.sourceBranch)` `` - person user3067684; 29.06.2020
comment
@ user3067684, я рад, что вы решили свой вопрос. Поскольку вы ее решили, не могли бы вы преобразовать свой комментарий в ответ? Это может быть полезно для других членов сообщества, читающих ответ, избегайте тратить много времени на сообщение, на которое уже есть ответ. Спасибо. - person Leo Liu-MSFT; 30.06.2020

Мое решение, если кто-нибудь найдет это .... Используйте условные выражения и если

condition: eq(variables['Build.SourceBranch'], variables.sourceBranch)

person user3067684    schedule 30.06.2020