Azure DevOps Server 2019保留策略不再起作用 [英] Azure DevOps Server 2019 Retention Policy no longer working

查看:36
本文介绍了Azure DevOps Server 2019保留策略不再起作用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

上周,我们已从TFVC迁移到ADS 2019.1服务器上的Git.

Last week we have migrated from TFVC to Git on our ADS 2019.1 server.

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

On our validation pipeline we have an aggressive retention policy. It is set to Keep for 2 days, 10 good builds with the branch filter * and all checkboxes cleared ADS writes it as: +refs/heads/*

我们看到的是,自迁移以来,没有任何Git构建被删除.从最近的8天开始,我们现在有了数百个构建版本,其GB下降了.

What we see is that since we migrated, none of the Git builds have been deleted. From the last 8 days we now have hundreds of builds with their multi-GB drop.

*是否可以使用正确的分支过滤器?这是ADS输入的默认设置,我们确实希望此策略删除所有分支的所有版本.

Is * the right branch filter to use ? This was the default setting entered by ADS, we do indeed want all builds for all branches to be deleted by this policy.

我也尝试过**,但是没有改变,在构建结果页面中,我看到所有构建都是从一个具有4位数字的临时分支构建的,该数字可能是拉取请求号.

I also tried **, but that made no change, in the build results page i see all build are build off a temporary branch with a 4 digit number, which is probably the pull request number.

我们如何确保根据保留政策对构建进行清理?

How can we ensure the builds are cleaned up as per the retention policies ?

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

The Build definition is not linked to a Release pipeline. The builds are triggered from the Pull Requests created by developers. The Pull requests are marked as Completed.

另一种构建定义(带有CI触发器,在每次提交后运行)仍然似乎会根据定义的保留策略删除构建.

Another build definition, one with a CI trigger that runs after every commit, does still seem to delete builds based on the retention policy defined.

我们的TFS保留策略设置的图片.主构建被清理,拉请求构建不被清理

Picture of our TFS Retention policy settings. Master builds are cleaned up, pull request builds are not

上周进行手动清理后,TFS中最旧的版本列表,这些版本现在已存在4-5天,超过了保留策略的2天限制.您还可以看到它们后面没有保持锁.

List of the oldest builds in TFS after manual cleanup last week, these builds are now 4-5 days old, over the 2 day limit of the retention policy. Also you can see there is no retain lock behind them.

已删除版本的概述.您可以在其中看到已被保留策略删除的主"版本.

Overview of the deleted builds. You can see 'master' builds in there that have been deleted by the retention policy.

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

Shows the master builds are deleted after the 2 day retention policy setting

推荐答案

您也可以尝试:

  1. 标签保留"
  2. 选择一个策略(在您的情况下:保留2天,[…]")
  3. 在分支过滤器"下,添加另一个
  4. 类型:包含",分支规范:"refs/pull/*"

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

Explaination: If you open a terminal in the build agent's source folder (named s) and run git branch --all, you will see a lot of branches like refs/pull/1234 for each pull request (e.g. 1234) there. Also, if you compare your branch specification * to the path shown on the left (+refs/heads/*) you see that it does in fact not match all branches…

这篇关于Azure DevOps Server 2019保留策略不再起作用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆