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

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），所以我会继续这样做。

关于控制垃圾邮件的问题 - 个人从来没有找到一种阻止构建系统被垃圾邮件阻止的好方法，我认为最好的策略是让人们可以在需要时轻松过滤掉（即主题标题可以用于电子邮件规则，或将所有邮件发送到专门用于构建垃圾邮件的共享电子邮件地址）。对不起，我没有更有用的建议。

让您的构建可追溯到源代码的荣誉！