1

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

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

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

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

使用标签来标记这些似乎是个好主意，允许您执行以下操作：

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

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

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

4

1 回答 1

2

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

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

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

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

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

于 2013-07-03T11:15:34.343 回答