TeamCity 和待处理的 Git 合并分支提交在测试失败的情况下保持构建
我们使用 TeamCity 进行持续集成，使用 Git 进行源代码控制。一般来说，它工作得很好——方便、现代，并且在测试失败时我们可以快速得到反馈。
有一个与 Git 合并细节相关的奇怪行为。以下是该案例的步骤：
- 第一个开发人员从主存储库中提取。
- 第二个开发人员从主存储库中提取。
- 第一个开发人员在本地提交 A。
- 第二个开发人员在本地提交 B；
- 第二个开发人员推送提交 B。
- 第一个开发人员想要推送提交 A，但无法推送，因为他必须先拉取提交 B。
- 第一个开发人员从远程存储库中提取。
- 第一个开发人员推送提交 A 并生成合并分支提交。
主存储库中的提交历史如下：
- B 第二个开发人员
- A 第一个开发人员
- 合并分支第一个开发人员。
现在，我们假设第二个开发人员在他的提交 B 中修复了一些失败的测试。TeamCity
将执行以下操作：
- 提交 B 到达 - TeamCity 生成构建 #1，所有测试均已通过
提交 A 到达 - TeamCity 生成构建 #2（没有提交） B) 测试栏变成红色！
TeamCity 认为待处理的“合并分支”提交不包含任何更改（任何新文件） - 但它实际上包含提交 B 的合并，因此 TeamCity 不想在此处进行新构建并进行测试绿色。
这里有两个问题： 1. 在我们的例子中，我们在第二次提交（提交 A）中返回失败的测试 2. TeamCity 不想进行新的构建并使测试恢复绿色。
有谁知道如何解决这两个问题。
我考虑一些合理的一般方法。
We use TeamCity for continuous integration and Git for source control. Generally it works pretty well - convenient, modern and good us quick feedback when tests fails.
There is a strange behavior related to Git merge specifics. Here are steps of the case:
- First developer pulls from master repo.
- Second developer pulls from master repo.
- First developer makes commit A locally.
- Second developer makes commit B locally;
- Second developer pushes commit B.
- First developer want to push commit A but unable because he have to pull commit B first.
- First developer pull's from remote reposity.
- First developer pushes commit A and generated merge branch commit.
The history of commits in master repo is following:
- B second developer
- A first developer
- merge branch first developer.
Now let's assume that Second Developer fixed some failing tests in his commit B.
What TeamCity will do is following:
- Commit B arrives - TeamCity makes build #1 with all tests passed
Commit A arrives - TeamCity makes build #2 (without commit B) test bar becomes Red!
TeamCity thought that Pending "Merge Branch" commit doesn't contain any changes (any new files) - but it actually does contain the merge of commit B, so the TeamCity don't want to make new build here and make tests green.
Here are two problems:
1. In our case we have failed tests returning back in second commit (commit A)
2. TeamCity don't want to make a new build and make tests back green.
Does anybody know how to fix both of this problems.
I consider some reasonable general approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只是补充一下，我强烈建议使用 git pull --rebase，或者完全只执行 git fetch，然后使用 git log -p ^master origin/master 修改已更改的内容，以确定我是否同意所发生的事情由于其他开发人员的工作。此时，我可以在远程更改的基础上重新调整我的工作，而 teamcity 不会给您提供您在此处看到的问题。这不是我围绕 teamcity 所做的事情，但也是工作流程的一部分，该工作流程允许更线性的历史记录和合并冲突解决方案，如果您要合并以前的合并，则无需重新访问。
HTH，
亚当
Just to add, I strongly advise on using git pull --rebase, or entirely just do a git fetch then do a revision of what has changed with git log -p ^master origin/master to determine if I'm ok with what happened due to other devs' work. At this point I can rebase my work on top of the remote changes and teamcity will not give you the problems you see here. This is not something I do to work around teamcity but is also part of a workflow that allows a more linear history and merge conflict resolutions that you do not have to revisit if you are merging previous merges.
HTH,
Adam
5.0.3 中尚未修复。但它被报告为已知问题
您可以在 http://youtrack.jetbrains.net 对此问题进行投票/issue/TW-9584
Is not yet fixed in 5.0.3. But it's reported as known issue
You can vote for this issue at http://youtrack.jetbrains.net/issue/TW-9584