使用 SVN 更新时，如何在 Hudson (CI) 中保留编译器警告？

Question

我使用 Hudson 进行了持续集成设置，最近我将作业配置为使用 svn update 来获取最新版本的代码。我真的很喜欢这种方法，因为它允许 msbuild 适当地进行版本控制并且只构建受影响的程序集。

但是，我注意到，由于我没有再次构建所有程序集，因此如果这些程序集没有构建，我会释放所有编译器警告。

例如，如果我有 3 个程序集，它们通过缩进展示了依赖关系：

• 程序集 1 10 个警告
  • 程序集 2（取决于 1）10 个警告
    • 程序集 3（取决于 2）10 个警告

第一次构建将构建所有 3 个程序集并记录 30 条警告。

下一个构建，如果我只更改 Assembly 3，Hudson 将只构建 Assembly 3，我只会收到 10 个该构建的警告，实际上将 20 个警告标记为“已修复”。

据我所知，没有办法解决这个问题，但我很想知道是否有人将 Hudson 配置为将这些编译器警告从一个构建保留到另一个构建。

编辑：是的，我意识到这可能会变成“你应该/不应该对 CI 框进行更新”的辩论，但我们采用更新方法是有原因的。

• 大约快 3 倍
• 我们仍在生产最新的组件
• msbuild can version the assemblies appropriately。

Answer 1

我会改变你的 CI 构建方法。在构建机器上进行增量构建非常具有误导性，并且仅具有边际价值（恕我直言），除非您的系统与操作系统一样大，否则您可能不会为自己节省太多时间。

如果您有不经常或从不更改的程序集，请将它们打包为“第三方”依赖项（甚至可能在合并模块中，以便您的部署可以轻松获取它们）并且不要使用 CI 重新构建它们。

另一方面，如果您的所有程序集都是易失性的（需要在一个发布周期中多次重建），请始终构建它们。

Answer 2

嗯，msbuild 正在做它应该做的事情：它只记录它遇到的警告。

如果你必须使用 svn update，唯一的办法就是：

• 解析构建日志并确定哪些程序集未构建
• foreach 未构建的程序集
  • 查看上次构建特定程序集的警告
  • 手动将这些警告转移到当前版本中。

它可能/可能不会笨重，它必须对 msbuild 日志格式有一个很好的理解。

也有人会争辩说它具有误导性，因为您会记录未针对该特定构建记录的警告。

Answer 3

您进行持续集成以查看一个程序集如何干扰其他程序集。因此，如果他们有依赖项，您应该全部构建。如果它们根本没有依赖关系，请为每个程序集创建一个作业（在您的情况下为 3）。

您描述的版本不是完整版本，它只是更新版本，应该在开发人员机器上完成。

编辑：版本问题

您可以配置 Hudson（与 SVN 相关）以忽略某些用户的提交。使用此黑名单，msbuild 进行版本控制应该没有问题。