【问题标题】:Prevent Pull Request builds from triggering Continuous deployment trigger Azure DevOps Server防止拉取请求构建触发持续部署触发 Azure DevOps 服务器
【发布时间】:2020-03-15 08:21:24
【问题描述】:

TL;DR

我们希望防止 Azure Devops 中的 Pull Request 分支策略构建通过 Continuous deployment trigger 机制触发发布。

问题

我们目前是 Azure DevOps Server 2019 版本 Dev17.M153.3 的用户

我们同时使用构建和发布管道。当用户提交拉取请求时,我们有一个 Branch Policy 将构建排队以确保代码编译并且所有测试都通过。此构建的完成会触发我们在相应版本的构建工件上配置的Continuous deployment trigger - 这对我们来说不是理想的行为。

我们的理想行为是让分支策略构建由拉取请求排队而不触发Continuous deployment trigger,因此不排队发布。如果我们手动排队构建,我们只想通过Continuous deployment trigger 触发发布。我们绝不希望在 Pull Request 上构建分支策略时发生这种情况。

我们尝试在Continuous deployment trigger 中使用Build branch filters,但没有成功。我已经尝试使用Exclude 设置它并将Build branch 设置为pull/*refs/pull/*merge,但这些过滤器没有任何运气,发布仍在排队。

我想知道是否有更好的方法来处理这种情况,或者是否可以将其他过滤器添加到 Continuous deployment trigger 以减少不需要的发布排队。

【问题讨论】:

  • 根据我的理解,你们想要的是无论PR是merge还是merge完成,都希望CD不能被触发。 (如果我有任何误解,请纠正我)。如果是这样,恐怕您正在使用的工作和@Shamrai 的答案将是您的最佳选择,尽管这些会有点复杂或带来另一个麻烦。因为 CD 意味着继续部署,一旦源有任何更新就会运行。
  • @MerlinLiang-MSFT 嘿梅林。感谢您的加入。是的,我相信您的理解是正确的。创建或更新 PR 时,会通过分支策略触发构建,我们不想 CD 构建该构建。感谢您的输入。我将考虑为拉取请求设置特殊构建。

标签: git powershell azure-devops azure-pipelines


【解决方案1】:

我们已经确定目前没有针对此问题的“最佳解决方案”,以下是一些替代方案。

简单的解决方法

  • 取消当前 PR 策略构建定义与发布定义的链接,并创建新的构建定义(或克隆退出)。将此新构建定义链接到您的版本并手动运行。
  • 从发布定义中删除持续部署,并从已完成的构建中手动创建发布。
  • 使用继续部署并将其设置为某个分支。然后,您的部署将仅在 PR 完成后触发(如果您为构建设置了 CI)。


释放变量和自定义条件(单个工件)

如果您的版本中只有一个工件,您可以使用 Build.SourceBranchName release variable 跳过作业级别的任务:

当变量表达式解析时,如果Build.SourceBranchName 变量等于merge,它会跳过以下所有任务:


发布变量和自定义条件(多个工件)

最后,如果您在发布中使用多个工件,您仍然可以完成上述行为,尽管您需要使用 PowerShell 脚本做一些额外的工作。

您使用 PowerShell 脚本查看 RELEASE_TRIGGERINGARTIFACT_ALIAS 环境变量,然后查看相应的 RELEASE_ARTIFACTS_<RELEASE_TRIGGERINGARTIFACT_ALIAS>_SOURCEBRANCHNAME 变量。

您的环境变量(在发布的Initialize Job 步骤中可见,如下所示。

...
[RELEASE_ARTIFACTS_PROJECT1_SOURCEBRANCHNAME] --> [master]
...
[RELEASE_ARTIFACTS_PROJECT2_SOURCEBRANCHNAME] --> [merge]
...
[RELEASE_ARTIFACTS_PROJECT3_SOURCEBRANCHNAME] --> [master]
...
[RELEASE_TRIGGERINGARTIFACT_ALIAS] --> [PROJECT2]
...

这在标准发布视图中也可见。

最终我们想看看触发工件的源分支名称变量是否设置为merge,如果是,我将发布短路并通过Control Options Custom conditions跳过所有后续任务。这不是一个理想的情况,因为 Pull Request 构建仍然会触发不必要的发布,但是,它会阻止任何实际的发布操作发生。

PowerShell 任务

下面是我目前在第一个任务中使用的 PowerShell

# Use the triggering artifact alias and constructing the name of the variable that will ultimately get us the source branch that triggered the release
$SrcBranchName = "RELEASE_ARTIFACTS_$(('$(RELEASE.TRIGGERINGARTIFACT.ALIAS)' -replace '(^\s+|\s+$)','' -replace '\s+','_').ToUpper())_SOURCEBRANCHNAME"

# Get the environment variable that holds the name of the source branch
$SrcBranchName = Get-Item  env:$SrcBranchName | Select-Object -ExpandProperty Value
Write-Host "SrcBranchName: $SrcBranchName"

if ($SrcBranchName -eq "merge") {
    Write-Host "Release caused by a PR - no further steps will run."
}

# Set an environment variable with the source branch name for use in a Custom Conditions Control
Write-Host "##vso[task.setvariable variable=TriggeringArtifactSourceBranchName;]$SrcBranchName"

自定义条件

然后对于我在每个任务中的自定义条件,如果 TriggeringArtifactSourceBranchName 设置为 merge,我会使用以下内容跳过任务。

and(succeeded(), ne(variables['TriggeringArtifactSourceBranchName'], 'merge'))

【讨论】:

  • 所以有几点注意事项 - 我们之前已经走过了多次构建的道路。它绝对可以解决问题,但是随着我们拥有尽可能多的构建,它变得难以管理。我认为分支过滤器将是一个完美的解决方案,但是,我们经常从功能分支手动构建,我们希望这些构建也能被持续部署所采用。最后,删除持续部署确实可以解决问题,但它非常方便,我很乐意把它扔到路边:(
  • @StevenZamborsky 您可以使用 Build.SourceBranchName 变量来查找源分支,然后在代理作业级别(而不是在每个任务上)跳过进程。我已经更新了我的答案
  • 感谢您的关注!只要您在一个版本中没有超过 1 个工件,这(对我来说)似乎是最好的答案。当您添加多个(不幸的是我们的场景)时,您需要对RELEASE_TRIGGERINGARTIFACT_ALIAS 进行一些复杂的操作,以找出实际触发了发布的原因,因为我相信BUILD_SOURCEBRANCHNAME 仅与RELEASE_PRIMARYARTIFACTSOURCEALIAS 相关。我将用我的解决方案更新你的答案并接受你的答案。
猜你喜欢
  • 1970-01-01
  • 2020-04-16
  • 1970-01-01
  • 2021-03-29
  • 1970-01-01
  • 1970-01-01
  • 2020-06-25
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多