问题标签 [build-automation]

我需要确定上次构建的状态（成功/失败），我这样做：

但这很浪费（加载整个 HTML 页面）、容易出错（我已经遇到了字节/unicode 错误）并且很脆弱。

在 VBP 中，可以通过创建自定义 COM 组件或自定义脚本来定义用户定义的操作。

我需要创建一个用户定义的操作iterative，这意味着它必须以迭代方式调用子步骤，就像内置操作的“流程文件”一样。

我不知道如何做到这一点，谷歌也没有帮助。

我想使用 NAnt 自动化 SVN 添加。我想将给定目录中的所有新文件添加到 SVN。NAnt 脚本将成功执行添加命令，但是它会显示 Tortoise SVN 添加对话框，这是不可接受的，因为它将在运行 CruiseControl 的构建服务器上执行。构建服务器正在运行 Windows Server 2003。

有任何想法吗？

我们在这里有一个持续的需求，我不知道如何使用库存的 Maven 2 工具和文档来解决。

我们的一些开发人员有一些运行时间很长的 JUnit 测试（通常是压力测试），在任何情况下都不应该作为构建过程/夜间构建的常规部分运行。

当然，我们可以使用 surefire 插件的排除机制并将它们从构建中剔除，但理想情况下，我们希望开发人员可以通过 Maven 2 随意运行它们。

我使用 Ant 构建 Delphi 应用程序（从 CruiseControl 调用）。

我希望 ant 递归搜索目录树以查找文件 *.dpr，并在找到时调用第二个 build.xml，或者最好是宏或目标，将找到的每个文件名作为“参数”传递。我发现我可以使用 subant 查找 build.xml 文件并按顺序运行它们，但这不是我想要的，因为我想避免为每个应用程序创建一个 build.xml。

我要避免的是必须在我的 build.xml 中逐项列出我的应用程序，而是让 ant 找到它们。

请不要告诉我使用不同的构建工具，因为我们已经在使用 Ant 方面进行了大量投资。

JsUnit提供了一个带有目标“standalone_test”的 ant 脚本。该目标使用属性 url 来识别执行测试的 HTML 站点。这些站点已签入，因此每个人都应该能够在签出后执行此测试。这可行，但 url-proprty 必须设置为绝对路径，例如file:///home/user/projects/my-project/path/in/project/jsunit/testRunner.html. 这避免了自动启动，每个人也都指定了一个命令，其中包含在他的盒子上构建的路径。是否可以改为传递相对路径/url，以便这些测试的执行可以自动化？这将有助于在我们的持续集成系统中设置这些测试。

工作中的构建机器有很多项目，但我们只遇到一个问题。

两个项目非常相似，一个在调试模式下构建，另一个在发布模式下。他们都清除了项目目录，然后从源代码安全中进行了完整的获取。调试版本很好且相当快地获得源代码，但发布版本需要很长时间才能获得源代码（它在 CheckingModifications 部分暂停很长时间，而调试版本不会暂停几乎一样长的时间）。源代码控制块是相同的（包含在单个文件中），如下所示：

任何人对为什么发布构建源代码控制块更慢有任何想法？

如果我手动将其粘贴到命令提示符中，它可以工作，但如果我从 python 运行它，我会得到The filename, directgory name, or volume label syntax is incorrect.

第一个批处理文件启动命令提示符，我需要第二个命令位于第一个命令的 ccontext 中。我怎么能在python中做到这一点？

照原样，它启动批处理，并阻塞直到批处理（及其命令提示符上下文）终止，然后在devenv没有必要上下文的情况下执行。

把它想象成我在 bash 中，我需要在 perl 上下文中执行命令，所以我输入perl -c 'asdf'. 背靠背执行 perl 和 asdf 将不起作用，我需要了解devenvperl 上下文的内部。

组织项目文件似乎有两个主要约定，然后是许多变体。

约定一：高级类型目录、项目子目录

例如，wxWidgets项目使用这种风格：

优点：

• 如果存在项目依赖项，则可以从单个文件进行管理
• 平面构建文件结构

缺点：

• 由于 test 有自己的头文件和 cpp 文件，当您为 EXE 文件而不是库生成单元测试应用程序时，它们需要包含您正在测试的应用程序中的目标文件。这需要您创建推理规则并扩展所有源文件的相对路径。
• 在另一个解决方案中重用任何项目需要您从树结构中提取正确的文件并修改任何构建脚本

约定2：高级项目目录，类型子目录

例如，Wireshark项目使用这种风格

优点：

• 项目本身在其文件夹中是独立的，使它们更易于移动和重用
• 允许在构建工具中使用更短的推理规则
• 促进分层构建脚本

缺点：

• 如果项目之间存在依赖关系，则需要在项目目录之上额外增加一层构建脚本来管理构建顺序

我们目前在我们的项目中使用约定 1，到目前为止它运行良好。现在，我正在添加单元测试（通过 CxxTest）并促进使用nmake迁移到持续集成，约定 1 在创建正确的 nmake 文件时引起了一些严重的麻烦。

我的主要要求/目标是：

• 减少维护整个解决方案的构建脚本的工作量。

• 将解决方案中的项目及其构建步骤与其他项目分离。

• 通过使用用于签出的构建脚本来促进持续集成，以发布每次提交的媒体生成（显然也利用其他工具，例如 CruiseControl）。

• 使添加或删除其他项目或源文件对开发人员来说尽可能容易且不易出错。

所以我问：

• 这两种方法还有其他优点和缺点吗？
• 是否有明确的规定只支持其中一种约定？