Azure DevOps - 给定版本中包含的所有工作项的可追溯性

Question

我需要在 PR 和版本之间具有完全的可追溯性——我希望能够查看哪个版本中实现了哪些工作项。

Azure DevOps 显然有 100 次提交的限制 - 这似乎完全是任意/随机的。更多信息请参见：Azure DevOps PR 消息 - “仅链接前 100 次提交的工作项”？

我的期望：我使用 GitFlow，因此我创建了一个拉取请求，例如

release/0.20.0

到

main

，并期望看到自上次发布以来附加到 PR 的所有工作项（即从

release/0.19.0

到

main

的 PR）。 我使用发布管道，我还可以在其中跟踪关联的工作项——但在这里，它也限制为 100 次提交！

我的问题：

• 是否可以增加此限制，以便考虑所有提交的工作项（而不仅仅是前 100 个）？ 100 次提交并不算多，我也不想 开始挤压。
• 这是否考虑了提交和/或实际的拉取请求？
• 是否有替代的自动化方式将合格的工作项目与给定的版本关联起来？
• 我注意到 PR 描述中提到的工作项也被添加了（如果它们在 100 次提交之内）。我们有时会在 PR 描述中提到“后续”工作项目。包括这些对我来说似乎是意外/不想要的行为。想法？

Answer 1

请检查以下答案，谢谢。

是否可以增加此限制，以便考虑所有提交的工作项（而不仅仅是前 100 个）？ 100 次提交并不是很多，而且我不想开始压缩。

您可以在一个拉取请求中包含

more than 100 commits

，它仅限制显示前 100 个提交中的链接工作项。这是目前设计的行为，

cannot

增加限制。

这是否考虑了提交和/或实际的拉取请求？

它不会影响PR中的真实提交，在合并拉取请求时会

NOT

丢失任何提交，这只是链接工作项显示的限制。

是否有另一种自动化方式将合格工作项目与给定版本关联起来？

目前，没有替代的自动化方式。

我注意到 PR 描述中提到的工作项也被添加了（如果它们在 100 次提交之内）。我们有时会在 PR 描述中提到“后续”工作项目。对我来说，包括这些似乎是意外/不想要的行为。

是的，会的

include the work items in the PR description

。

当你合并PR，并使用

build pipeline

创建工件时，检查结果页面，工件实际上已经包含

all work items

。如果您使用

release pipeline

中的工件作为源，它将列出相同的工作项，其中包括描述中的工作项。

在上面，两种行为都是正确的并且是当前设计的。如果您想改变这种行为，建议在社区链接中提出功能请求，谢谢。