这是一个关于我们应该如何使用来自持续集成系统的标记的问题。
显然，构建系统会尝试为大多数提交进行构建，如果它们之间的距离太近，则会跳过其中的一些提交，并为每个提交提供一个构建号。
生成的结果可能是以下结果之一：*生成系统故障（生成计算机或类似计算机上没有足够的磁盘空间）*生成失败*测试失败*成功
现在最大的问题是，是否将这些信息存储在SCM（通常是git或mercurial）中是个好主意。
使用标签来标记这些似乎是一个好主意，可以让你做一些事情，比如：
- 在修订版上记录标记
build=1234 - 如果成功，则将标记
last-success移动到当前生成 - 将标记
last-build移动到上一个生成（未通过测试） - 添加标签
build_url=http://buildsystem.example.com/job/1234 - 也许还有其他变化
现在，我还想知道是否从构建系统向SCM历史记录中发送标记更新。
这是正确的方法吗？——我仍然对向SCM中输入太多信息和产生太多电子邮件通知的副作用感到担忧。
从本质上讲，这看起来可以归结为确保您可以从给定的构建追溯到创建它的源代码（反之亦然）-我看到了解决这个的两种通用方法
- 您提到的解决方案-在SCM中用内部版本号标记代码（标记是显而易见的方法）
- 相反-将SCM的修订号存储在由内部版本生成的软件包中（例如，让内部版本吐出一个包含软件包中包含的SCM修订号的小文本文件）
我想说，这两种解决方案都运行得很好，最好的解决方案取决于您打算如何使用这些信息。例如，如果您的动机是，在调试生产系统上的问题时，您可以很容易地检查出该软件版本的相关源代码，那么方法（2）工作得很好，因为在生产系统上查找SCM修订号并检查出该修订的代码很容易。然而，你也有很多好的理由更喜欢你的问题中列出的选项（1），所以我同意。
就你关于控制电子邮件垃圾邮件的观点而言，我个人从未找到阻止构建系统成为垃圾邮件的好方法，我认为最好的策略是让人们在需要时轻松过滤掉它（即可以在电子邮件规则中使用的主题标题，或将所有邮件发送到专门用于构建垃圾邮件的共享电子邮件地址）。对不起，我没有更有用的建议了。
让您的构建可追溯到源代码，值得称赞！