来自持续集成构建系统的源代码控制标记策略

Question

这是一个关于我们应该如何使用来自持续集成系统的标记的问题。

显然，构建系统将尝试构建大多数提交，如果它们彼此太接近，则会跳过其中一些，并为每个提交提供一个构建号。

构建的结果可以是以下之一： * build-system-failure（构建机器或类似机器上没有足够的磁盘空间） * 构建失败 * 测试失败 * 成功

现在最大的问题是将这些信息存储在 SCM（通常是 git 或 mercurial）中是否是个好主意。

使用标签来标记这些似乎是个好主意，让您可以做以下事情：

1. 在修订版上记录标签build=1234
2. 如果成功则将标签 last-success 移动到当前构建
3. 将标签 last-build 移动到最后一个版本（未通过测试）
4. 添加标签build_url=http://buildsystem.example.com/job/1234
5. 可能还有其他变化？

现在我也想知道如何使用来自构建系统的标签更新向 SCM 历史发送垃圾邮件。

这是正确的方法吗？ -- 我仍然担心将过多信息放入 SCM 并有过多的电子邮件通知作为副作用。

Answer 1

基本上这看起来归结为确保您可以从给定的构建追溯到创建它的源代码（反之亦然） - 我已经看到了解决这个问题的两种通用方法

1. 您提到的解决方案 - 使用内部版本号标记 SCM 中的代码（标记是执行此操作的明显方法）
2. 相反 - 将 SCM 的修订号存储在您的构建生成的包中（例如，让构建吐出一个小文本文件，其中包含包含在包中的 SCM 修订号）。

我会说这两种解决方案都运作良好，而最好使用的解决方案取决于您打算如何使用这些信息。例如，如果您的动机是，在生产系统上调试问题时，您可以轻松查看该软件版本的相关源代码，那么方法（2）很有效，因为它很容易查找 SCM 修订号在您的生产系统上查看该版本的代码。但是，您也有很多充分的理由选择问题中列出的选项 (1)，所以我会同意。

就您关于控制垃圾邮件的观点而言 - 个人从未找到阻止构建系统成为垃圾邮件的好方法，我认为最好的策略是让人们在需要时轻松过滤掉它（即主题标题可以用于电子邮件规则，或将所有邮件发送到专门用于构建垃圾邮件的共享电子邮件地址）。抱歉，我没有更有用的建议。

感谢您使您的构建可追溯到源代码！