3

在一个反复无常的设置中，我想根据持续集成脚本自动标记某些构建。例如，一个标签，例如branchName-buildId每当部署一个分支的构建时，或者latest-stable每当一个构建通过所有集成测试时。

但是，我担心简单调用的直接方法hg tag会导致问题：

  • 一些标签可能是重复的 - 即latest-stable。我真的不在乎在这种情况下哪个构建被标记，但我不想要任何冲突，因为脚本无法解决这些问题。
  • 标签导致提交。然而，这意味着这些提交需要被推送，并且它们需要在面对人类和其他脚本的并发推送时保持稳健。特别是，自动推送会产生额外的正面，这是不好的。但是当检测到额外的头（在推送时）时，本地标签提交已经发生，即使新的头可能很容易合并，有时标签也会导致冲突。

我怎样才能自动让 CI 服务器健壮地标记构建？在这里，更重要的是最终结果是一致的（即它不会弄乱 CI 服务器或 repo），并且在面对重复或冲突时可靠地应用标签并不重要（无论如何这应该是不太可能的） ）。

4

2 回答 2

1

我认为你的谨慎是对的。机器人并不总是最好的公民，而且经常会做一些愚蠢的事情。

你最终会做什么取决于你看到标签的用途。例如，如果您只看到 CI 系统使用它们，那么我建议将它们保留在本地。完全没有拉/推/合并问题。

一些标签可能是重复的 - 即最新稳定。我真的不在乎在这种情况下哪个构建被标记，但我不想要任何冲突，因为脚本无法解决这些问题。

如果已经定义了一个标签，并且您hg tag再次调用，除非您强制它，否则它将失败，但是这样做是添加一个更新的、稍后定义的相同标签，并且最新的一个获胜。一方面这很好，因为合并很简单，但是在你这样做的时候考虑一​​下情况：

hg update -r latest-stable
hg update -r latest-stable
hg update -r latest-stable
hg update -r latest-stable

每次您更新到该版本时，您都会在制作标签之前获得一个版本（正常），并且该版本latest-stable将指向之前的latest-stable. 结果是，这一系列命令将使您穿越时空。

因此，我会说最好stable-2013-02-18在两个提交中使用唯一标签（即 ）或标签；一个删除旧标签，一个添加新标签。

hg update -r latest-stable # You're now at the commit that removed the tag.
hg update -r latest-stable # This one will error because tag doesn't exist

标签导致提交。然而，这意味着这些提交需要被推送，并且它们需要在面对人类和其他脚本的并发推送时保持稳健。特别是，自动推送会产生额外的正面，这是不好的。但是当检测到额外的头（在推送时）时，本地标签提交已经发生，即使新的头可能很容易合并，有时标签也会导致冲突。

CI 机器人应该tag; pull; merge (if necessary); push. 如果合并失败，不要推送，发出警报。如果推送失败（即在合并时有更多变更集），请再次拉取并合并。我只是确保您的脚本非常明确地说明了它正在合并的修订。这个过程应该让你没有多余的头脑。

我相信 Mercurial 对.hgtags合并文件的处理方式不同，因为它知道内容，因此冲突应该非常罕见。此外，标签提交通常很容易合并，因为所有更改都是.hgtags，因此来自 CI 头部的合并永远不会冲突。它可能的唯一原因是因为其他人使用与 CI 服务器相同的标签名称，如果他们这样做，那么他们需要在键盘上倒蜂蜜，这样他们才能造成更多的伤害。

我可以看到导致问题的情况是，如果您在多个具有相同标签名称的磁头上进行 CI 标记。例如，开发和发布分支都在其上运行 CI，都分配了tests-clean标签，但分配给不同的修订版，然后稍后合并。解决方案是，不要那样做。

希望其中一些是有帮助的。

于 2013-02-18T17:14:28.647 回答
0

如果您关心构建历史，请考虑为构建过程创建一个命名分支。在 Mercurial 中，来自所有分支的所有标签在整个存储库中都是可见的。

如果你不关心历史书签应该做的伎俩。构建过程可以latest-stable在测试运行后设置书签，然后执行hg push --bookmark latest-stable以将该书签推送到服务器。

无论哪种方式，您都必须注意不要对已经测试过的子版本进行测试。Mercurialrevsets是非常强大的查询语言，应该会有所帮助。

于 2013-02-18T17:18:55.067 回答