TFS 2010 API-从合并中获取工作项 [英] TFS 2010 API - Get work items from merge

问题描述

我需要在TFS 2010中完成构建后发送一封电子邮件，其中详细说明了与已作为此构建的一部分进行编译的签入关联的工作项.通过使用构建工作流程中可用的associatedChangesets变量，此操作没有问题.

I need to send an email on completion of a build in TFS 2010 which details the work items associated with check-ins that have been compiled as part of this build. This works no problem via use of the associatedChangesets variable available in the build workflow.

但是，在生产情况下，我们会将合并从Development分支合并到Release分支.在这一点上，该构建认为只有一个更改-这就是前面提到的Development与Release的合并.显然，这是毫无用处的，因为我们需要找出合并的分支中进行了哪些更改以及关联的工作项.

However, in a production situation, we will merge changes from our Development branch into a Release branch. At this point, the build considers there to have only been one change - which is the aforementioned merging of Development into Release. Obviously this is fairly useless as we need to find out which changes where made in the branch that was merged in, and the work items associated.

有人知道如何使用TFS 2010 API来完成此任务吗?从API角度来看，它的文档似乎很少.我知道您可以在VS2010中扩展合并历史记录"节点，但是显然这不好，因为需要以编程方式收集此数据，以便可以发送报告电子邮件.

Does anyone know how to accomplish this using the TFS 2010 API? It seems to be fairly poorly documented from an API perspective. I know you can expand the merge history node in VS2010 but obviously this is no good as this data needs to be collected programatically so a report email can be sent.

推荐答案

好...我认为我找到了一个解决方案，尽管它很笨拙，但实际上我不确定它是如何工作的.但是到这里-也许它将指向正确的方向.

OK... I think I found a solution to this although it's clunky and truth be told I'm not exactly sure how it works. But here goes - maybe it will point someone in the right direction.

var associatedWorkItems = new List<WorkItem>();

//Passed in from the build workflow (this variable is available under the 'Run On Agent' sequence as 'associatedChangesets'
IList<Changeset> associatedChangesets = context.GetValue(BuildAssociatedChangesets);

if (associatedChangesets.Count > 0)
{
    var projectCollection =
        new TfsTeamProjectCollection(new Uri("http://localhost:8080/tfs/DefaultCollection"));
    VersionControlServer versionControlServer = projectCollection.GetService<VersionControlServer>();

    foreach (var changeset in associatedChangesets)
    {
        //In order to view the individual changes, load the changeset directly from the VCS.
        Changeset localChangeset = versionControlServer.GetChangeset(changeset.ChangesetId);

        foreach (Change change in localChangeset.Changes)
        {
            //Find out what was merged in.
            ChangesetMerge[] mergedChangesets = versionControlServer.QueryMerges(
                null,
                null,
                change.Item.ServerItem,
                new ChangesetVersionSpec(localChangeset.ChangesetId),
                new ChangesetVersionSpec(localChangeset.ChangesetId),
                null,
                RecursionType.Full);

            //Extract work item information from changesets being identified as merged.
            foreach (var changesetMerge in mergedChangesets)
            {
                Changeset actualChange = versionControlServer.GetChangeset(changesetMerge.SourceVersion);

                foreach (WorkItem item in actualChange.WorkItems)
                {
                    if (!associatedWorkItems.Exists(w => w.Id == item.Id))
                    {
                        associatedWorkItems.Add(item);
                    }
                }
            }
        }
    }
}

不要问我QueryMerges的工作原理，但是我在这里所做的所有事情都是要告诉我什么是变更集检入的一部分.您会注意到参数ChangesetVersionSpec是相同的-这意味着我们只是在看这个变更集的合并.

Don't ask me exactly how QueryMerges works but all I'm doing here it saying show me what what merged as a part of a changeset checked in. You'll notice that the parameters ChangesetVersionSpec are the same - this means we're just looking at merges from this one changeset.

您将从QueryMerges()取回ChangesetMerge对象的数组.在ChangesetMerge类中，有一个名为SourceVersion的属性-这是合并的原始变更集的ChangesetId.一旦确定，就可以使用VersionControlServer.GetChangeset()方法加载单个集合并提取该集合. WorkItem.然后将其添加到WorkItems列表中，该列表可以按照您想要的任何方式进行操作(在我的情况下为电子邮件).我还使用了.Exists()检查来确保相同的WorkItem不会被记录两次.

You'll get back an array of ChangesetMerge objects from QueryMerges(). In the ChangesetMerge class there is a property called SourceVersion - this is the ChangesetId of the original changeset merged in. Once we've got that we can use the VersionControlServer.GetChangeset() method to load the individual set and extract the WorkItem. This is then added to a list of WorkItems which can be manipulated in any way you want (in my case an email). I also used the .Exists() check to make sure the same WorkItem doesn't get recorded twice.

请注意，即使您具有构建工作流程中的集合associatedChangesets，出于某种原因(至少对我而言)，也不会填充associatedChangesets中的Changes[]属性(因此，使用VersionControlServer.GetChangeset()方法，因为这似乎实际上填充了我们需要的所有字段.

Note that even though you have the collection associatedChangesets from the build workflow, for some reason (for me at least), the Changes[] property inside associatedChangesets was never populated (hence loading each individual changeset using the VersionControlServer.GetChangeset() method as this seems to actually populate all the fields we need.

就像我说的那样，1.这是一个笨拙的解决方案(很多循环-其中一些可能是不必要的)，2.尽管看起来似乎可以产生所需的结果，但我并不完全了解它的工作原理-我来到了通过大量的测试和调试来得出这个结论)，最后-基于Microsoft提供的可悲文档，这是我能想到的最好的结果.

Like I say, 1. this is a clunky solution (lots of looping - some of which is probably unecessary), 2. I don't fully understand how this works although it seems to produce the required results - I came to this conclusion by doing a lot testing and debugging) and finally - it's the best I could come up with based on the woeful documentation provided by Microsoft.

希望它对某人有帮助！

这篇关于TFS 2010 API-从合并中获取工作项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！