问题标签 [gated-checkin]

以前，XAML 门控构建用于仅使用一个门控构建定义签入属于不同解决方案的 TFS 中的多个工作区的文件。

我的意思是，就像开发人员过去只使用一个门控构建定义来检查 TFS 中的多个文件，即使这些文件的工作空间没有映射到旧的 XAML 门控构建定义中。

但是在迁移到 TFS 2017 更新 3 之后，情况就不一样了，我们必须为 TFS 中不同路径上的每个解决方案创建单独的门控构建定义。（虽然我会说这是一个很好的做法，并且可以防止在 TFS 中检查任何损坏的代码，但它的缺点是为我们签入的每个解决方案和文件更改创建了多个更改集）

为避免出现多个变更集问题，一种选择是创建一个门控构建定义，该定义将为我们拥有并将构建的所有 8 个解决方案映射工作区，并允许开发人员使用一个门控构建定义签入多个文件，但它也有它的缺点构建时间将无缘无故地增加，即使您签入一个文件，它也会构建其他解决方案。

那么是否有任何其他选项可以解决这个问题，即允许开发人员通过一个门控构建本身签入多个文件并同时维护代码完整性检查？

我们使用 gitflow。当创建并批准拉取请求时，我们希望运行一个封闭的构建。成功后希望从拉取请求提交创建发布分支。这个提交构建应该得到门控批准。您能否指导我查看文档或如何实现这一点

当尝试使用指定的变更集（或门控签入）运行 TFS 2015 构建时，我们在构建开始时收到错误：

所以这看起来是TF UNSHELVE命令的问题......我以 TFS 代理用户帐户登录服务器并手动运行命令：

这在我按照要求配置了 tf 工作区集合之后起作用。请参阅初始命令错误。

有什么想法可以让我找到有关实际失败的更好信息吗？我没有收到好的错误消息。我在 eventvwr.msc 日志中看不到任何相关内容。

• 如果未指定变更集，则构建运行良好
• 我删除了工作区并允许构建重新创建它 - 没有帮助

编辑：更多信息，看起来像 TFS 中的错误？除非有人知道解决方法，否则看起来我们将不得不推迟 GC，直到我们更新 TFS。

我在 Azure DevOps 中使用门控签入创建的最后两个项目遇到了困难。

我收到的错误：

[Error]The shelveset [ommitted] could not be found for check-in

我们正在使用本地代理，我创建的最后两个项目在门控签入时出现此错误。但是，我们具有相同构建管道的旧应用程序似乎运行良好，所以我不明白为什么会发生这种情况。

有没有人有任何想法？

我们将 Sonarqube 8.0 和 TFS 与门控签入一起使用。因此，当我签入使质量门变红的代码版本时，我们破坏了构建并且签入被拒绝。但是如果我再次签入完全相同的代码，sonarqube 只会分析新代码，因此门又是绿色的，因为与上次分析没有区别，它是红色的。所以我们在哪里想把“新代码时期”作为最后的绿色分析，但这似乎是不可能的。我只能选择“以前”“天数”和“特定”。对我来说，这没有多大意义，因为我只想看看我当前的签到有什么变化。也许我们必须分析主分支，并且只将分析设置为检查主分支的特定版本，

我知道这种分析更适用于从私人项目中获取 master 的拉取请求，但我们这里没有 git，所以现在没有选择。

有没有一种好方法可以使用 sonarqube 保持我们的开发分支清洁？现在结合 TFS 和单个 DEV 分支感觉有点没用……</p>

我对触发器部分下的 TFS 2017 Build 中提供的选项有点困惑。我有两个单独的构建定义，一个用于代码签入，即称为门控构建，另一个是手动构建，我们用于在门控构建完成后在我们的 CI 服务器上进行代码删除\部署。

最近，我们考虑直接使用 Gated 构建定义进行代码删除，这样可以节省单独触发手动构建的时间。但是，在执行此 POC 时，我对使用“触发器”部分中可用的不同功能感到困惑，尤其是“为提交的更改运行持续集成触发器”

我已经将 Gated Build 与 Release Definition 直接关联起来，一旦 Gated Build 完成，它就会部署代码。我在构建中选择了两个选项，即为 过滤器使用工作区映射和为提交的更改运行持续集成触发器。每当我签入代码时，构建完成后都会触发发布定义并将代码部署在服务器上，但是当我取消选择运行持续集成触发器以进行提交的更改并签入代码时，它仍然会部署代码，因为它与发布定义相关联。

我在谷歌上搜索并试图了解它的使用和其他功能，但不太了解，我通过链接也知道它不会在变更集中显示 NO CI。

任何人都可以解释触发器下存在的每个功能\选项的确切用途，除了计划的一个，或者如果有任何其他链接、博客、视频教程，请告诉我任何知道触发器选项下所有功能的解释的人深入举例？

在 CI 构建中启用了持续集成选项，因为它会在门控构建完成后自动触发。

目前，我们在 TFVC 中使用一个开发分支，每个开发人员都可以在其中签入。我们有一个 Gated Checkin 来确保我们的项目能够构建。

现在我们想切换到 git，但 TFS 2017 和 Azure DevOps 2019 没有类似于 git 存储库的门控签入。我们可以更改我们的工作流程以使用功能分支和拉取请求。但是拉取请求仅在合并到 master（或另一个分支）时测试代码。

如果每个功能都由单个开发人员开发，这将是可以的。但在我们的大多数功能中，不止一个开发人员在一个功能上工作。我们如何防止开发人员将代码推送到中断构建并阻止同一分支上的其他开发人员的分支？

我们有一个映射的工作区，其中每个项目都有对其他项目的多个引用。在同一个工作区，我们每晚执行整个产品构建。

当我们为单个项目启用门控签入时，它会创建一个新的工作区并尝试构建。由于其他项目未映射为门控签入的一部分，因此无法构建。

我们有没有办法在 tfs 构建中获取在门控签入期间创建的搁置集，以便我们可以使用它在本地映射工作区中取消搁置？

任何帮助/领导表示赞赏。

我的工作区在门控登记后无法协调。我没有看到错误。我的文件已签入，但仍显示在未决更改下。

• 与最新的比较显示没有差异。
• 如果我绕过门控登记，它会按预期进行协调。
• 单击构建菜单上的“协调工作区”会显示一个对话框，显示“没有更改协调”。
• 重新启动 Visual Studio 不协调。

我们的团队刚收到新电脑，每个人都遇到这个问题。这确实需要我们安装最新版本的 Visual Studio 2019 (16.8.4)。我不确定这是最新的 Visual Studio 还是新计算机的问题。

关于如何解决这个问题的任何建议？

我正在尝试在 Azure 管道中启用门控签入，我的每次签入在最后阶段都失败签入门控更改并出现错误[错误] 找不到搁置集 _Build_24;Build\BUILD-GUID-NUMBER 进行检查-在

我试图找到这个问题的解决方案，我找到了一些通过以下步骤解决这个问题的链接： 用户设置>>预览功能>>为我>>禁用“使用多个队列构建” 不幸的是，我找不到这个选项在给定的位置。

可能会为旧版本的 Azure 提供正确的解决方案，现在此选项不可用，或者我指的是错误的地方。

请帮助我解决方案或提供一些有用的链接，以便我从中获得想法/理解。