我需要在2010 TFS构建,详细介绍与已编译为这个构建的一部分签入相关的工作项目完成后发送电子邮件。这通过使用associatedChangesets
变量可用在构建工作流工作没有问题。
然而,在生产的情况下,我们将合并从我们的发展分支变成一个发布分支。在这一点上,构建认为那里有只出现过一次的变化 - 这是发展的上述合并到发行。显然,这是相当无用的,因为我们需要找出哪些变化,其中在被合并的分支的,并且工作项目相关联。
有谁知道如何使用TFS 2010的API来实现这一目标?这似乎是相当从API的角度不良记录。我知道你可以扩大在VS2010合并历史节点,但显然这是没有好,因为需要这些数据进行编程,以便收集报告的电子邮件可以被发送。
OK ......我想我找到了一个解决这个虽然它的笨重,说实话我不太确定它是如何工作。但在这里不用 - 也许它会指向一个人在正确的方向。
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
是相同的参数 - 这意味着我们只是看着从这个变更合并。
你会得到ChangesetMerge
对象从QueryMerges()
数组。在ChangesetMerge
类有一个叫做SourceVersion
属性 - 这是当初变更的ChangesetId
在合并一旦我们得到了我们可以使用VersionControlServer.GetChangeset()
方法加载个人设置和提取WorkItem
。这是然后添加到它可以在任何你想要的方式进行操作(在我的情况的电子邮件)WorkItems
的列表。我还使用了.Exists()
检查,以确保同一WorkItem
不会被记录两次。
请注意,即使你有从构建工作流程的集合associatedChangesets
,由于某种原因(至少对我来说),内部Changes[]
的associatedChangesets
财产从未填充(因此使用VersionControlServer.GetChangeset()
方法,因为这似乎真正填充所有加载每个人变更领域我们需要的。
就像我说的,1。这是一个笨拙的解决方案(大量循环的 - 其中一些可能是不必要的),2。我不完全理解它是如何工作的,虽然它似乎产生所需要的结果 - 通过我得出这一结论做了很多的测试和调试),最后 - 这是我能想出的基于微软提供的文档前景堪忧上最好的。
希望它可以帮助别人!