Azure DevOps Server 2019 保留策略不再起作用答案

【问题标题】：Azure DevOps Server 2019 Retention Policy no longer workingAzure DevOps Server 2019 保留策略不再起作用
【发布时间】：2020-05-15 03:43:18
【问题描述】：

上周，我们在 ADS 2019.1 服务器上从 TFVC 迁移到了 Git。

在我们的验证管道中，我们制定了积极的保留政策。设置为保留 2 天，使用分支过滤器 * 的 10 个良好构建，并清除所有复选框 ADS 将其写为：+refs/heads/*

我们看到的是，自从我们迁移以来，没有一个 Git 版本被删除。从过去 8 天开始，我们现在有数百个构建，它们的数 GB 下降。

* 是正确的分支过滤器吗？这是 ADS 输入的默认设置，我们确实希望所有分支的所有构建都被此策略删除。

我也试过 **，但没有任何改变，在构建结果页面中，我看到所有构建都是从一个临时分支构建的，带有 4 位数字，这可能是拉取请求编号。

我们如何确保按照保留政策清理构建？

构建定义未链接到发布管道。构建是由开发人员创建的拉取请求触发的。拉取请求被标记为已完成。

另一个构建定义，一个在每次提交后运行的 CI 触发器，似乎仍然根据定义的保留策略删除构建。

我们的 TFS 保留政策设置图片。清理主构建，不清理请求请求构建

上周手动清理后 TFS 中最旧的构建列表，这些构建现在有 4-5 天的历史，超过了保留政策的 2 天限制。您还可以看到它们后面没有保留锁。

已删除构建的概述。您可以在其中看到已被保留策略删除的“主”构建。

显示主版本在 2 天保留策略设置后被删除

【问题讨论】：

你使用发布管道吗？您的发布管道上的保留是多少。如果您选择在发布管道上保留工件，它将使用发布保留而不是构建保留。
嗨@Matt，不，我们不为此定义使用发布管道，我已在原始帖子中添加了更多详细信息
如果你想让它适用于所有，为什么不删除所有分支过滤器。
那是因为 TFS 强制你有一个“你必须添加至少一个分支过滤器。”

标签： tfs azure-devops azure-pipelines

【解决方案1】：

Azure DevOps Server 2019 保留策略不再有效

同意马特的观点。如果发布管道的工件是 Build，则构建管道将使用发布保留而不是构建保留：

所以，我们需要检查发布保留，Project Settings->Release retention：

您可以从文档Build and release retention policies-Q&A 中查看此信息。

此外，如果构建被无限期保留，保留政策将不再适用。

希望这会有所帮助。

【讨论】：

感谢cmets，我了解ADS的基本原理。此定义仅链接到拉取请求，没有链接到此构建定义的发布定义。此外，构建未标记为无限期保留。所以它唯一的链接是拉取请求。但我认为我们不需要自己删除拉取请求。
@Nico，感谢您的回复。那么，那些保留的管道来自拉取请求？
正确，此定义中的“所有”构建都已从拉取请求中排队。它可能与分支过滤器选项有关，但默认为 * 我认为这必须有效。
我发现了一个更早之前迁移到 Git 的构建定义。在这里我发现了一些有趣的东西。此定义还配置为使用分支过滤器 * 删除除几天之外的所有构建。这里也没有删除任何构建，但在已删除的选项卡中，我确实看到了从 12 月删除的构建。删除的原因是“构建已被保留策略删除，因为它在 30 多天前完成。” 30 天是在最大保留期下设置的值。所以它回到了那个设置。所以我真的怀疑这与分支过滤器有关。
@Nico，确认一些信息。你说的分支过滤器是触发器选项卡下启用持续集成的分支过滤器吗？您可以在问题中提供一些屏幕截图，这将有助于我们更好地理解您的问题

【解决方案2】：

你也可以试试：

标签“保留”
选择一项政策（在您的情况下：“保留 2 天，[…]”）
在“分支过滤器”下，添加另一个
类型：“包含”，分支规范：“refs/pull/*”

说明：如果您在构建代理的源文件夹（名为s）中打开一个终端并运行git branch --all，您将在那里看到很多分支，例如refs/pull/1234，每个拉取请求（例如1234）。此外，如果您将分支规范 * 与左侧显示的路径 (+refs/heads/*) 进行比较，您会发现它实际上不匹配所有分支......

【讨论】：

感谢@Christian 的建议。我昨天做了这个改变，提供的 ADS 过滤器看起来很有希望。但是今天我还没有看到已删除的版本。最早的版本是从 2020 年 2 月 18 日上午 7:08:59 开始的，应该是 2 天前。我会让它在周末像这样运行，看看会发生什么。我的过滤器现在显示：+refs/heads/*,+refs/pull/*
再次感谢克里斯蒂安！您的建议似乎解决了“该版本已被保留政策删除，因为它在 2 天前完成”的问题
遗憾的是，它仍然没有修复 CI 构建的保留，仅适用于拉取请求构建。
我也有同样的问题。我有 20 个构建管道（没有发布管道），并且在所有这些管道上，保留策略（自动清理）都不能很好地工作。昨天我在这篇文章中添加了建议的过滤器refs/pull/*，因此至少现在已经删除了 pr 构建（在单个管道上对此进行了测试）。但是仍然有一个构建遗留下来，它是手动触发的，并且来自一个特性分支，应该已经被删除了。你们找到解决方案了吗？ ADS 2020 更新能否解决这个问题？
我想我发现了问题：Minimum to Keep 的描述指出，该数字适用于每个分支。因此，如果您有 main 分支的构建和 branch 功能的构建，则两者都不会被删除，因为它们是这些分支的最后构建。

【解决方案3】：

保留策略 UI 极具误导性，因为 * 并不是真正的 * - 它是 refs/heads/*。当 UI（或者可能是 API）保存“分支规范”时，它会隐式地将 +refs/heads/ 添加到您输入的任何内容中。 main 变为 +refs/heads/main，mybranch/* 变为 +refs/heads/mybranch/*。

您可以通过查看 [Build].[tbl_Definition] 中 RetentionPolicy 列中的 JSON 来看到这一点（假设默认集合 DB 名称）：

SELECT [DefinitionName],[RetentionPolicy]
FROM [Tfs_DefaultCollection].[Build].[tbl_Definition]

默认的构建保留策略，永远不会匹配拉取请求分支，存储为：

[
  {
    "branches": [
      "+refs/heads/*"
    ],
    "artifacts": [],
    "artifactTypesToDelete": [
      "FilePath",
      "SymbolStore"
    ],
    "daysToKeep": 10,
    "minimumToKeep": 2,
    "deleteBuildRecord": true,
    "deleteTestResults": true
  }
]

TFS 作业代理的构建保留策略作业在每个构建定义中调用一次存储过程[Build].[prc_GetBuildsForRetention]，以获取要清理的潜在构建列表。版本保留的构建已从查询结果中排除。

您可以使用这样的查询自行尝试（更新 definitionId 和 maxFinishTime，可能还有 dataspaceId 和 partitionId）：

EXEC [Tfs_DefaultCollection].[Build].[prc_GetBuildsForRetention]
    @partitionId = 1,
    @dataspaceId = 22,
    @definitionId = 164,
    @minFinishTime = '0001-01-01',
    @maxFinishTime = '2021-08-03',
    @maxBuilds = 1000

你会看到类似这样的结果：

要将拉取请求包含在您的保留策略中，请添加一个新条目并在分支规范框中键入 refs/pull/*。这将作为+refs/pull/* 持续存在于JSON 中。您可能希望将“保持天数”设置为低（我使用 1）和“最少保持”低（我使用 0）。我们的 PR 版本将在几个小时后到期，因此将它们保留更长时间没有什么好处。

为了将来参考，构建保留策略作业代码位于<installFolder>\Application Tier\TFSJobAgent\Plugins\Microsoft.TeamFoundation.Build2.Server.Extensions.dll 类中的Microsoft.TeamFoundation.Build2.Server.Extensions.BuildRetentionPolicyJob。

【讨论】：