Azure Devops 延迟了持续集成构建

Question

我目前有一个 Azure Devops 安装，我正在为自动构建和测试进行配置。我想为构建过程启用持续集成触发器，但是我们的签入标准要求我们代码的不同部分彼此分开签入。

例如：我们正在使用 nettiers 自动生成的代码，因此每当票证需要更改数据库时，nettiers 代码库就会更新。因为这是自动生成的代码，所以它与手动修改分开签入，并带有注释，表明它是自动生成的签入。

如果没有同时签入 nettiers 和手动修改，则构建将失败。但是，在启用持续集成的情况下，第一次签入将触发构建开始，该构建将缺少后半部分更改几分钟后检查。

我想解决这个问题的理想方法是在 CI 构建第一次被触发和它实际开始工作之间实现 5 分钟的延迟。如果每次连续签入都会取消第一个构建并使用自己的构建启动一个新计时器以考虑任何后续签入，那就更好了。

解决该问题的另一种方法可能是在工作项查询上设置一个门。然而，我在弄清楚如何实施这些想法或提出其他选择方面一直没有成功。基于查询的 Gates 似乎只在发布管道中可用，而不是在构建中。

有没有人解决过类似的问题，或者对如何解决或解决这个问题有想法？

Answer 1

Azure Devops 延迟了持续集成构建

恐怕没有这样的开箱即用设置/方法来设置此为您的案例指定持续集成构建。

作为解决方法，我们可以生成代码并使用 nettiers 签入到某些指定文件夹，例如 \NettiersGenerated。

然后我们可以通过Enable continuous integration 下的Path filters 排除该文件夹：

在这种情况下，生成的代码不会触发构建管道。

更新：

这将要求始终首先签入 nettiers 代码 （这将很难执行）

是的，同意你的看法。如果没有同时签入nettiers和手动修改，构建将失败，那么我的第一个确实不够合理。

作为另一种解决方法，我们可以使用 Azure DevOps 计数器并通过 powershell 脚本获取计数器的其余部分，仅当数量为偶数时才构建管道，否则取消构建，例如：

反表达式如

variables:
  internalBuildNumber: 1
  semanticBuildNumber: $[counter(variables['internalBuildNumber'], 0)]

Powershell 脚本：

$value=$(semanticBuildNumber)
switch($value)
  {
    {($_ % 2) -ne 0} {"Go on build pipeline"}
    {($_ % 2) -eq 0}
      {
         Write-Host "##vso[task.setvariable variable=agent.jobstatus;]canceled"
         Write-Host "##vso[task.complete result=Canceled;]DONE"
      }
  }

在这种情况下，管道将在第二次触发时构建。

希望这会有所帮助。