问题标签 [gated-checkin]

我这里有一个情况；我设计了我的 TFS Team Build 2012 构建模板，如下所示

1. 运行代理范围内的所有活动，门控签到除外
2. 在构建成功和失败的情况下发送邮件（邮件带有变更集详细信息
3. 自上次成功构建到此构建），发送邮件活动发生在 finally 块中（在代理范围内）
4. 门控登记（这通常是要执行的最后一步，在代理范围之外）

现在，我的问题是：

1. 如何在我的邮件通知中包含通过 Gated-Checkin 发生的变更集。
2. 我无法在 AgentScope 内推送 Gated Checkin 活动，也无法在 Agent Scope 外拉出发送电子邮件活动。

如何处理？

使用视觉工作室 2012 和 tfs 2012。

“构建”签入政策和门控签入之间有什么区别？他们似乎都需要成功构建才能签入。

它们两者的优点和缺点是什么？

应该优先使用一个还是可以/应该一起使用它们？

我正在使用 TFS 门控签到。我注意到每次签入一个 javascript 文件时，它也会触发构建，这会浪费很多时间。

如果签入 javascript 文件（或其他类似文件类型），如何防止触发构建？

当我定义了一个门控构建时，当有人签入代码时，工作项的集成构建字段更改为门控构建号（当然，如果开发人员将他的签入与工作项相关联）。触发 CI 构建后，此字段将更改为 CI 构建号。

我的问题是：一旦触发了门控构建，有没有办法不更改工作项的集成构建字段？

编辑

让我更清楚地了解我们的工作方式。

我们有几个工作项目（一些是用户故事，一些是错误）。当开发人员签入代码时，他或她会将他/她的签入与那些在集成构建字段中获得已解决状态和“Gated xxxx”的用户故事相关联。我们从不测试门控构建。取而代之的是，每天晚上我们手动触发构建，这些工作项会再次更新，但这次在集成构建字段中带有“Release xxxx”。第二天，我们测试了这些工作，但过程继续进行，开发人员继续检查更多的美国或错误（将有门控......）。

有时我们会感到困惑，我们会测试不应测试的工作项目，因为它们处于“门控状态”。

即使我们的分支无法解决我们的问题，因为开发人员将签到与工作相关联，而我们无法更改。

我们不测试封闭式构建，因为我们的 QA 团队很小。开发团队有 20 名开发人员，而 QA 团队只有 2 名。部署应用程序的过程大约需要 10 分钟，每个开发人员签到都要等待 10 分钟，这可能会很痛苦。而且在我们测试时更改代码永远不会一个好主意，因为它会干扰我们的测试。

有人可能会认为我们的流程是错误的并提出新的方法。这将是非常受欢迎的，但是除了那个小问题之外，我们所做的工作非常好。

正如预期的那样，我有一个引发异常的构建后脚本（powershell）。构建后脚本在“构建后脚本路径”部分的构建定义中定义。异常记录在构建的“其他错误和警告”部分。

启用门控签入后，即使构建被归类为“部分”，更改仍会提交（因为构建后脚本失败）。

似乎只有在 MSBuild 失败或单元测试失败时才会拒绝提交。

如何拒绝对部分构建结果的任何提交？

我在 TFS 中使用 Workspace.Checkin 命令时遇到错误，因为我尝试签入的文件是门控构建定义的一部分。有很多人询问如何使用 TFS API 覆盖门控签到。但一个非常不同的问题是：如果我真的想以编程方式执行门控签到怎么办？如何在 TFS API 中触发它？

我想做的是：

1. 对一组挂起的更改执行正常的签入操作
2. 接收有关已启动的封闭式构建的信息
3. 订阅该构建的完成事件，或轮询构建直到它完成。
4. 如果构建成功并提交更改，则继续（如果可能，获取生成的更改集）
5. 如果构建不成功则停止，并报告错误。

我找不到任何东西来回答这个问题；也许这是一个极端情况，我是唯一一个疯狂到想要这样做的人。也就是说，我对此的需求是合法的。我唯一能想到的是，我需要通过门控签入过程的较低级别功能：1）遍历构建定义以查看任何文件的路径是否与任何路径一致在任何封闭式构建中。2) 如果存在交叉点，则创建挂起更改的搁置集 3) 使用搁置集对门控定义的新构建进行排队 4) 查询构建定义并刷新信息，直到构建状态完成 5) 如果构建成功，取消搁置挂起的更改，然后使用覆盖签入。

但是，请注意，即使我执行了这些步骤，生成的构建也不会看起来像一个封闭的构建。将发送策略覆盖通知，让某人知道实际执行构建的唯一方法是将此类信息包含在策略覆盖注释中。有没有更直接的方法可以让它看起来像任何其他封闭式构建？

通过浏览器（服务器名称：8080/tfs/DefaultCollection/MyProj/_Build）查看构建历史记录时，我发现有许多缺失的构建条目是通过门控签入触发的。当我仅过滤该构建定义时，与数百个代码签入相比，我发现了少数条目。

所有开发人员都必须使用封闭式构建，并且所有签入都显示成功的迹象（NO_CI）

使用 API，我发现相同的结果，这是根本问题......

什么会导致这种行为？

在签入特定文件类型（即“.config”）时，是否可以通过编程方式在 TFS 2010 中的 Gated -Check in build 中不触发 Gated Build？我怎样才能做到这一点？

我知道 NuGet 恢复可能会在包文件夹和包含的文件上放置签出锁。但是，为什么在 Gated Checkin Build 由于编译错误而失败时，TFS Build 不释放这些锁呢？

当 Gated Checkin Build 失败时，Visual Studio 不允许取消搁置更改，因为文件被构建服务器上的 TFS 服务锁定。

TFS Sidekick 显示多个文件被 TFS 服务帐户锁定。

新的构建系统非常令人兴奋。但...

我想知道是否有任何方法可以使用 TFS 版本控制创建带有门控签入的构建定义，就像它在 XAML 构建定义中可用一样？

它是一个隐藏的选项还是很难找到？如果没有，是否有可能开发一个扩展来做到这一点，还是我们必须等待 MS 支持它？