Как создать конвейер политики ветвей Azure DevOps, который также выполняет «имитируемую» сборку и тестирование слиянием?

Судя по дальнейшим обсуждениям требования к тестированию кода после слияния исходной ветки с целевой веткой PR, нам, похоже, не нужно тестировать после фактического слияния с удаленной main веткой, а затем создавать новую sim-merge ветвь; вместо этого мы можем рассмотреть возможность обновления (объединения или перебазирования) локальной основной ветки на машине агента сборки проверки PR с применением предложенных изменений.

Следуя этому направлению, я протестировал образец конвейера проверки PR, приведенный ниже, для вашей справки.

trigger: none

pool:
  vmImage: windows-latest

steps:
- checkout: self # During a PR validation build checkout: self will checkout the intermediate PR branch of refs/pull/{prId}/merge
  fetchDepth: 0 # Disable shallow fetch to keep the related history between branches
  persistCredentials: true

- powershell: |
    git checkout -b $(System.PullRequest.targetBranchName)
    
    Write-Host Pull from the remote $(System.PullRequest.targetBranchName) branch
    git pull origin $(System.PullRequest.targetBranchName)
    
    Write-Host Merge the changes from $(Build.SourceBranch) into current local $(System.PullRequest.targetBranchName) branch on agent
    git fetch origin $(Build.SourceBranch):refs/remotes/origin/pull-$(System.PullRequest.PullRequestId)
    git merge origin/pull-$(System.PullRequest.PullRequestId)
    
    tree $(Pipeline.Workspace) /F /A
  condition: eq(variables['Build.Reason'], 'PullRequest')

- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '**/*.sln'
    feedsToUse: 'select'

- task: VSBuild@1
  inputs:
    solution: '**\*.sln'

- task: VSTest@3
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
      **\PRVSTestDemoTests.dll
      !**\*TestAdapter.dll
      !**\obj\**
    searchFolder: '$(System.DefaultWorkingDirectory)'
    resultsFolder: '$(Pipeline.Workspace)\TestResults'

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

Azure DevOps уже делает все, что вы хотите, «за кулисами». При создании PR первое, что делает AzDO, — это создает временную фиксацию слияния путем слияния исходной ветки с целевой веткой и сообщает вам, есть ли какие-либо конфликты. Вы можете просмотреть этот временный коммит слияния, используя меню из трех точек и выбрав «Просмотреть изменения слияния». Идентификатор фиксации этого временного слияния — это фиксация, с которой вам следует запускать тесты.

Вы также можете просмотреть и получить идентификатор фиксации из командной строки:

git ls-remote # all branches and PRs will be listed

# Suppose the PR # is 1234

git ls-remote | grep pull | grep 1234

# the result looks like this:
f42ba4e3b25008d393bc175d864fba435636dfb6      refs/pull/1234/merge

# you can fetch that commit either with the commit ID or the ref
git fetch origin refs/pull/1234/merge
# or
git fetch origin f42ba4e3b25008d393bc175d864fba435636dfb6

Теперь этот идентификатор фиксации: f42ba4e3b25008d393bc175d864fba435636dfb6 — это именно то, что вам нужно использовать для вашего теста.

Примечание. Временная фиксация слияния автоматически обновляется каждый раз, когда вы отправляете обновления в исходную ветку. Он не обновляется при обновлении целевой ветки. Если PR устарел и вы знаете, что целевая ветка была обновлена ​​с момента создания последней фиксации слияния, вы можете принудительно обновить фиксацию слияния в трехточечном меню PR, выбрав «Перезапустить слияние». Обычно вы запускаете тесты сразу после создания PR или новых коммитов в исходную ветку, поэтому в это время они всегда будут актуальными.

Azure DevOps уже делает это.

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

Временная ветка использует соглашение об именах refs/pull/<pull-request-id>/merge. Ветка автоматически удаляется после завершения запроса на включение.

Хотя эти ветки не отображаются в пользовательском интерфейсе Azure Repos, вы можете добавить в свой .git/config следующее, что позволит вам перенести ветку в локальную среду для проверки.

[remote "origin"]
    fetch = +refs/pull/*/merge:refs/remotes/origin/pull/*/merge