Gated Check-in将不正确的工作项与Changeset相关联 [英] Gated Check-in associates incorrect work items to Changeset

问题描述

TFS 2017（On-Prem）

VC：TFVC

当我的用户通过门禁办理登机手续办理登机手续时，许多工作项与变更集相关联。 

步骤：

1）对源控制文件进行更改。

2）没有关联任何工作项，签到触发门禁登记构建

3）成功构建后，许多（在我们的例子中为5-40）工作项现在与变更集相关联。

每次构建都是成功的，它似乎添加了越来越多的工作项。这是我们的责任和我们的工作流肆虐。

解决方案

构建查看工作区映射和上次成功构建，并关联自上次签入以来链接到工作区中文件的所有工作项。

链接到工作区的工作项触发构建的变更集可能是其中之一，但构建会检测自上次构建以来的所有关联工作项，从问责制角度来看更正确。

工作项的关联方式有在TFS 2015和2017之间进行了更改，2015年它不会查看构建工作区设置，但会查看最高共享根文件夹并将所有工作项关联在其下。

我怀疑你需要在Agent 2.x上获得最准确的关联，同时我还没有检查和比较。

TFS 2017 (On-Prem)

VC: TFVC

When my users check-in through a Gated Check-In, many work items become associated with the changeset. 

Steps:

1) make a change to a source-controlled file.

2) Without associating any work items, check-in triggering a Gated Check-In Build

3) After successful build, many (in our case 5-40) work items are now associated with the Change Set.

The build is successful each time, and it seems to add more and more work-items. This is wreaking havoc on our accountability and our work flow.

解决方案

The build looks at the workspace mapping and the last successful build and associates all work items that were linked to files in the workspace since the last check-in.

The work items linked to the changeset that triggers the build is likely one of them, but the build detects all associated work items since the last build, which from an accountability perspective is more correct.

The way workitems were associated has changed between TFS 2015 and 2017, in 2015 it would not look at the builds workspace setting, but would look at the highest shared root folder and would associate all work items beneath that.

I suspect you need to be on Agent 2.x to get the most accurate associations, again somethign I haven't checked and compared yet.

这篇关于Gated Check-in将不正确的工作项与Changeset相关联的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！