构建验证管道导致分支被锁定的解决方法咨询

问题描述 #

我配置了一个Azure DevOps CI管道，用于dev分支和所有features/*分支的构建验证，管道YAML如下：

trigger:
- dev
- features/*

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    command: 'restore'
    restoreSolution: '**/*.sln'
    feedsToUse: 'select'
    vstsFeed: 'devops-nuget-guid'

将该管道设置为分支的构建验证管道后，出现以下问题：开发者首次推送分支并触发管道运行后，分支的安全设置被自动修改，导致无法推送后续提交，报错信息如下：

$ git push
Enumerating objects: 19, done.
Counting objects: 100% (19/19), done.
Delta compression using up to 20 threads
Compressing objects: 100% (13/13), done.
Writing objects: 100% (13/13), 8.16 KiB | 522.00 KiB/s, done.
Total 13 (delta 6), reused 0 (delta 0), pack-reused 0
remote: Analyzing objects... (13/13) (602 ms)
remote: Storing packfile... done (88 ms)
remote: Storing index... done (58 ms)
To ssh.dev.azure.com:v3/Company/Project/Repo
 ! [remote rejected] features/123-dv-BranchDescription -> features/123-dv-BranchDescription (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)
error: failed to push some refs to 'ssh.dev.azure.com:v3/Company/Project/Repo'

手动修改分支权限可临时解决，但无法通过UI批量为features/*的子分支设置权限，因此需要找到可行的解决方案。

解决方案1：阻止构建验证管道修改分支安全设置 #

在Azure DevOps仓库的分支策略中，找到针对dev和features/*的构建验证规则，编辑该规则：

• 取消勾选**“要求通过拉取请求才能进行更改”**（该选项会强制禁用直接推送，仅允许通过PR更新分支）
• 保存修改后，构建验证管道仍会在分支推送或PR提交时运行，但不会自动锁定分支的直接推送权限。

解决方案2：自动为features分支设置允许推送的安全规则 #

使用Azure DevOps CLI或REST API批量配置features/*分支的推送权限，可将该逻辑整合到定时管道或现有构建管道的末尾：

Azure CLI示例 #

# 登录Azure DevOps组织
az devops login --org https://dev.azure.com/YourOrganization

# 为Contributors组设置features/*分支的推送权限
az repos permission update \
  --org https://dev.azure.com/YourOrganization \
  --project YourProjectName \
  --repository YourRepoName \
  --branch features/* \
  --subject "Contributors" \
  --allow BitwiseOr \
  --permission-id 2

说明：permission-id 2对应“推送”权限；subject参数可替换为具体的开发者组或用户。

PowerShell调用REST API示例 #

$orgUrl = "https://dev.azure.com/YourOrganization"
$projectName = "YourProjectName"
$repoName = "YourRepoName"
$pat = "YourPersonalAccessToken" # 需要具备权限管理的PAT

# 构建请求头
$headers = @{
    Authorization = "Basic " + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat"))
}

# 获取仓库ID
$repoId = (Invoke-RestMethod -Uri "$orgUrl/$projectName/_apis/git/repositories?api-version=7.1-preview.1" -Headers $headers).value | 
          Where-Object { $_.name -eq $repoName } | 
          Select-Object -ExpandProperty id

# 获取Contributors组的Descriptor
$contributorDescriptor = (Invoke-RestMethod -Uri "$orgUrl/$projectName/_apis/identity/groups?api-version=7.1-preview.1" -Headers $headers).value | 
                         Where-Object { $_.displayName -eq "Contributors" } | 
                         Select-Object -ExpandProperty descriptor

# 设置推送权限
$permissionBody = @{
    accessControlEntries = @(
        @{
            descriptor = $contributorDescriptor
            allow = 2
            deny = 0
            extendedInfo = @{}
        }
    )
}

Invoke-RestMethod -Uri "$orgUrl/$projectName/_apis/git/repositories/$repoId/refs/heads/features/*/permissions?api-version=7.1-preview.1" `
                  -Method Put `
                  -Headers $headers `
                  -Body ($permissionBody | ConvertTo-Json -Depth 10)

解决方案3：其他可行方案 #

改用普通CI触发器替代构建验证管道 #

如果不需要将构建验证作为PR的强制前置条件，仅需在分支推送时自动触发构建，可直接使用现有管道的trigger配置（无需将其设置为分支策略的构建验证）。这样管道会在分支推送时正常运行，且不会修改分支的安全权限。

配置分支权限继承 #

在Azure DevOps仓库的分支权限设置中：

1. 找到refs/heads（所有分支的父节点），确保开发者组拥有“推送”权限
2. 针对features/*分支，设置权限为**“继承父权限”**
3. 对于已被修改权限的现有features/xxx分支，手动重置为“继承父权限”，或删除后重新创建分支以继承权限。

内容的提问来源于stack exchange，提问作者Dewey Vozel