TeamCity 和待处理的 Git 合并分支提交通过失败的测试继续构建

Question

我们使用 TeamCity 进行持续集成，使用 Git 进行源代码控制。一般来说，它工作得很好 - 方便、现代并且在测试失败时快速反馈给我们。

有一个与 Git 合并细节相关的奇怪行为。以下是案例的步骤：

1. 第一个开发者从主存储库中提取。
2. 第二个开发人员从主存储库中提取。
3. 第一个开发者在本地提交 A。
4. 第二个开发者在本地提交 B；
5. 第二个开发者推送提交 B。
6. 第一个开发人员想要推送提交 A，但由于他必须先拉取提交 B，所以无法推送。
7. 第一个开发者从远程仓库拉取。
8. 第一个开发者推送提交 A 并生成合并分支提交。

主仓库中的提交历史如下：

• B 第二开发者
• 第一个开发者
• 合并分支第一个开发者。

现在让我们假设 Second Developer 在他的提交 B 中修复了一些失败的测试。

TeamCity 将做的事情如下：

1. 提交 B 到达 - TeamCity 构建 #1 并通过所有测试

2. 提交 A 到达 - TeamCity 使构建 #2（没有提交 B）测试栏变为红色！

3. TeamCity 认为待处理的“合并分支”提交不包含任何更改（任何新文件） - 但它实际上包含提交 B 的合并，因此 TeamCity 不想在这里进行新构建并将测试变为绿色。

这里有两个问题： 1. 在我们的例子中，我们在第二次提交（提交 A）中返回失败的测试 2. TeamCity 不想构建新版本并让测试恢复绿色。

有谁知道如何解决这两个问题。

我考虑了一些合理的通用方法。

Answer 1

补充一下，我强烈建议使用 git pull --rebase，或者完全只是做一个 git fetch 然后用 git log -p ^master origin/master 修改已经改变的内容，以确定我是否还好由于其他开发人员的工作而发生的事情。在这一点上，我可以在远程更改之上重新调整我的工作，并且 teamcity 不会给你你在这里看到的问题。这不是我为解决 teamcity 所做的事情，但它也是工作流的一部分，它允许更线性的历史记录和合并冲突解决方案，如果您正在合并以前的合并，则无需重新访问。

HTH，

亚当

Answer 2

在 5.0.3 中尚未修复。但它被报告为已知问题

你可以在http://youtrack.jetbrains.net/issue/TW-9584为这个问题投票