使用Hudson进行持续集成(七)
译自： http://www.javaworld.com/javaworld/jw-12-2008/jw-12-hudson-ci.html
- Project name :我已经把这个项目命名为HeliosJMXTrunk ，但你也可以在这里修改它。
- Description : 这是一个自由项，主要用来说明你关于这次构建工作的描述。可不填。(帮助:这说明放在项目的首页，以便访问者可以知道这个工作的内容。您也可以在这里使用任何HTML标记。)
- Discard old builds : Hudson默认将保留过去的构建，除非你事先选中此框。(帮助:这里控制着您想要在Hudson所在的磁盘把构建记录存储的有效期(诸如控制台输出、编译构件等等)。Hudson为此提供了两个标准：1。时间驱动。在Hudson中您可以判断如果达到一定时限来删除一条记录(例如，七天前)。2。数量驱动。在Hudson中您可以确保它拥有N份构建。如果又有新的构建开始，最早的那份(记录)就将被删除。Hudson也可以让您建立的个别构建定义为'永远保持这个记录'，以便防止某些重要的构建被自动丢弃。)
- This build is parameterized : 如果选择此选项，Hudson将允许您提供一套任意的键值对参数，它们会被传递到构建过程里。配置的参数往往是构建运行环境中的一些环境变量。(帮助：当您使用了Hudson的各种自动化，有时要求在构建过程中提供一组用户的输入，使用“parameterize”就能够更方便构建。例如，您可能会设立一个按需测试，在那里用户可以提交一个二进制文件的压缩文件来进行测试。
本节参数可以完全按照您构建的需要配置。参数是以名字区分的，所以您可以有多个参数，只要它们名称不同。
关于此功能的更多资料请查看维基专题讨论 。) - Enable project-based security : Hudson支持全面的安全方案，可以强制用户在通过身份验证后，再访问Hudson网页;它也可以通过控制用户的权限来管理用户的工作。在这个Hudson例子中我没有配置安全
[你可以参考我的另外两篇文章：Use Hudson之标准安全设置和使用matrix security对Hudson进行细粒度Job的安全控制，获取关于安全的详细配置]。 - Disable build : 如果这里被勾选，这项工作将不会执行构建，直到选项禁用为止。(帮助：有时候，你会想暂停某个构建中的项目。例如，也许您正准备一次大的迁移，而且你知道新版本会失败。或者您想每一个小时构建一次，但您却发现CVS服务器将在未来24小时内down机。当这个选项被设置后，关于这个项目就不会再有新的构建。这样一来，您就可以在不想改变外部依赖或者提交错误通知的情况下禁用构建过程。)
- Advanced options : 我没有使用这些选项，但是当此复选框被选中时，选项中就会暴露下面的接口：
- Quiet period : 在这里您可以配置一个静态监控，当构建准备按某个计划运行时，实际上它就已经在开始执行了。
- Use custom workspace : 默认情况下，Hudson将在${jboss-home}/.hudson/jobs/[项目名称](注:Linux环境 )下创建一个工作区 。此选项将允许您使用指定的地址替代(它)。
- Source code management : 在默认情况下是这三个选项：
- Subversion
- CVS
- None
：一个先决条件是要有一个源代码仓库。但我坚持认为，在大多数情况下，为Hudson选择某个仓库是绝对必要的。本文稍后，我将讨论如何安装Hudson插件。如果您安装了一个与SCM相关的插件，并重新启动Hudson，那么在这个清单上也将出现一些新的选择。本文，我使用 Subversion 。当您选择Subversion后，将展开一个配置表单。我会在下面的某一部分中单独描述这个配置(见“ Subversion的工作配置” ) 。 - Build after other projects are built : 此选项支持一条装配(流水作业)线——作业依赖: 一个作业依赖于另一个作业的输出的情况 —— 或者如以下情形：你只是想简单的把一些有关的工程构建编入一个组以便一起构建。当您一选择它，你将得到一个字段，输入其他工程的名字[多个项目名间用逗号分隔]后，这个构建应该就可以运行。
- Poll SCM : 这是CI 系统中常见的选项。当您选择此选项，您可以指定一个定时作业表达式来定义Hudson每隔多久检查一下您源代码仓库的变化。如果发现变化，就执行一次构建。例如，表达式中填写0,15,30,45 * * * *将使Hudson每隔15分钟就检查一次您源码仓库的变化。更多信息请查阅Quartz CronTrigger中关于这个定时作业语法的详细描述(新版Quartz支持从秒开始触发，所以请查阅下面的cron帮助，对此引起的误导表示歉意)。
-
Build periodically : 此选项 (也是使用定时作业表达式)仅仅通知Hudson按指定的频率对项目进行构建，而不管SCM是否有变化。我这个作业就属于目标测试环境是按某种方式定期修订的而SCM却是静态的情况。如果您想在这个作业中运行一些测试用例的话，它可能就很有帮助。
-
Add build step : 按一下这个按钮，添加了一项指令以执行构建脚本。您的指令可以是下列之一：
- 执行 Shell
- 执行 Windows 批处理
- 使用Ant(这是我将要使用的选项，在下面我会做详细的说明)
- 使用Maven
- Archive the artifacts : 当您选择此选项，就可以指定文件和目录的掩码(Ant风格的掩码，可以指定包含与排除)，当与掩码相匹配的构件在构建时将被添加到Hudson的构件仓库，它们会用作业（名）和构建序号来标识。所有以前构建过的构件可以选择性地丢弃，以节省您Hudson服务器上的磁盘空间。
- Record fingerprints of files to track usage : 当您选择此选项，它使用类似Ant方式的掩码，恁可以指示Hudson去生成构件的指纹码，确保您能够更容易地找到它们的位置，另外判断系统中的这些构件是否还在使用。
- Publish javadoc : 如果您的构建脚本能生成JavaDoc，此选项将指示Hudson发布这些内容，而且立即把它公布在当前工作的主页上。每一个成功构建的文档内容都可以保留，但在默认情况下只保留最新的。
- Publish JUnit test result report : 如果您的构建脚本执行了JUnit测试，此选项将指示Hudson处理XML测试文档并为每次连续构建产生一份可持续的报告，依据正在进行的测试汇总处理结果。其结果是当前工作主页的一份报告，作业中的单元测试会随着时间的推移按由老至新进行陈列。
- Aggregate downstream test results : 在某些情况下，作业中一组单元测试花费的时间大大长于实际构建它所花的时间。在这些情况下，你可以选择把构建和测试分为不同的作业，以便完成构建能相对迅速，一旦与这相关的一个或多个测试作业就执行完毕，构建也就成功完成了。 当您选择这个选项， Hudson就会把构建后作业的测试结果进行统计，并且能追溯到它们的明细。用以做为本次构建成功或失败的主要依据。
- Build other projects : 较之前面的选项，这个选项主要用来实现一个合乎逻辑的构建和测试过程，它会被分为两个或两个以上的物理工作，并且会按顺序执行。当此项被选择后，您将得到一个字段，可以在其中输入您想在当前作业中后执行的其它作业名[多项作业可用逗号分隔]。即使目前的作业得出结论说构建可能不稳定，您也可以选择这样做。(关于“作业的稳定性”请查阅“作业状态”章节以获取更多信息)
- E-mail notification : 当您选择此选项，您可以输入一个或多个电子邮件地址[多个可用空格分隔]，当Hudson完成了执行作业后，将会给它们发送通知。事件触发时将产生一份Email，包括构建失败、构建不稳定等。这儿有一个额外的选项，当由于用户的错误提交造成Hudson决定废弃此次构建，将会发送一份专门的邮件给这位SCM提交者，以便让他检查源代码。
Ha！Ha！看来这些信息太多了，让您有点无法把握吧！没关系，为了让您更好的掌握这一切，您将在下面看到一个构建作业的样例。这样一来，您就会了解到这些配置项是如何运用到实践中的。
在Hudson配置一次构建作业:示例
下面是一个如何在实际作业中配置我的Hudson服务器。这项作业构建的是我命名为“HeliosJMX”的实用类库。这一节的所有图片都是我为了描述上一节而因此新建一个作业的截图。
在图14中，您可以看到项目的名称、说明和一个废弃策略。(指示Hudson保持过去5次构建，但废弃更前的构建。)
图14. 作业示例, 第一部分
图15显示了在此次作业中Subversion的安装位置。 这个Subversion仓库的URL网址存放在java.net上： https://helios.dev.java.net/svn/helios/helios-jmx/trunk(貌似现在进不去了，因为需要密码
)。Local module directory属性是一个可选的和额外的子目录，它将为此次构建创建一个工作区。
“Use update”复选框是很重要的。这是Hudson准备从工作区构建执行前先刷新Subversion仓库以获取最新源码的最快捷的方式。这一动作是行之有效的，并在大多数情况下也相当快。警告，如果源构件已从仓库删除，工作区也会利用此步骤持续更新源码。另一种选择当然是禁用此选项，若是这样，Hudson将清除工作区并从源码仓库中重新注入。
最后一个选项是指定一个源代码仓库浏览器，诸如FishEye或VisualSVN 。如果您拥有下面列表提供这些产品的一种，就选择适合的浏览器并把它指着自己的源代码仓库地址。
图15. 作业示例, 第二部分
在图16中，您可以看到我填写的构建触发器详情：我每隔5分钟就检查一次Subversion，它们一有变化就构建一次。
(帮助:该字段遵循cron[Linux下任务定时系统]的语法(两者间仅仅有轻微差异)。
具体来说，每行由TAB键或空格隔开的5个字段组成：
MINUTE HOUR DOM MONTH DOW
MINUTE 一小时内多少分钟（0-59）
HOUR 一天内多少小时（0-23小时）
DOM 一个月内多少天（1-31）
MONTH 每月（1-12）
DOW 星期几（0-7），其中0和7都表示周日。
如果要指定一个字段允许多个值，就按下面提供的操作步骤(指定)。
优先顺序如下：
'*' 可用来指定所有有效的值。
'M-N' 可以用来指定一个范围,比如“1-5”
'M-N/X'或'*/X' 可用于在指定范围内跳跃一个X的值，比如在MINUTE字段中"*/15"表示"0,15,30,45"，"1-6/2"表示"1,3,5"。
'A,B,...,Z' 可以用来指定多个值，比如“0,30”或“1,3,5”。
任何空白行和'#'开始的行都将表示为注释而不予理睬。
此外，''@yearly', '@annually', '@monthly', '@weekly', '@daily', '@midnight', '@hourly'都是支持的 。
举例说明：
＃每分钟
* * * * *
＃每一小时后第5分钟
5 * * * *
)
图16. 作业示例, 第三部分
图17显示了我定义的Ant任务，以便执行构建过程。配置选项如下：
- Ant version : 指定一个Ant实例，以执行构建。
- Targets : 指定的Ant脚本文件中的一系列目标将被调用。这里可以留空，在这种情况下，脚本默认的任务将被执行。
- Build file : Ant脚本执行完后的存放路径，它跟当期工作区是同级目录。
- Properties : 这些额外定义的系统属性将可以通过这里传递到Ant脚本中。我这里的脚本包含了一些属性以便通过我的Subversion仓库的身份验证，因为我的程序中包括了一个把一些改变放回仓库的步骤。此外，我还定义了另一些属性，以便为我的单元测试配置参数。
- Java options : Java的命令行选项可以通过这里传递。有了这个配置，您就可以使用Ant -debug，即一边调试脚本中存在的问题，一边让Ant有选择生成一份特定的诊断日志。其它常见的选项如指定Java的最小和最大的堆栈大小(-Xms 和 -Xmx )，这提醒您将在Hudson中启用一个新的JVM实例来运行您的构建脚本。
图17. 作业示例, 第四部分
图18显示了构建完成后我定义的一些动作：
- Archive artifacts : 当构建一旦完成，就会指示Hudson归档已构建的构件。这是一个Ant方式的掩码，用来指定一个目录把与之关联的工作区、文件名和一些扩展文件进行归档。归档后的这部分(文件)可以在当前构建实例的主页上很容易的获取到。高级选项还允许你指定一个排除掩码，你可以选择删除所有存档过的构件，除了最后一次成功的构建产生的构件。
- Publish javadoc : 类似上面的选项，它适用于在构建的过程中产生的任何Javadoc内容。
- Publish JUnit test result report : 指示Hudson在定义的路径上获得一个JUnit XML结果文件，并且汇总它们到历史趋势报告。
图18. 作业示例, 第五部分
图19显示了构建完成后我定义的更多的动作：
-
Publish FindBugs analysis results : 我的构建脚本执行FindBugs静态代码，它用于分析作业的源代码，并生成一个调查报告。此选项表明Hudson FindBugs插件已安装。它指示Hudson检索FindBugs XML结果报告，汇总它们到当前作业的历史趋势中并且暴露在当前作业的主页上。FindBugs插件的高级选项允许您当FindBugs上报时确定断言的类别，以及在Hudson获取关于当前作业的状态时，它们将如何影响最终的测定。(更多信息请查阅关于题为"作业状态"这一节)
-
E-mail notification : 定义一个邮件列表( 多项用空格间隔),以便当构建失败时发送一份通知。当一次作业总是不稳定或者被终止，"Send email for every unstable build "就可以不选，以阻止Hudson不断发送一份已获知条件的邮件通知。
-
Publish Cobertura coverage report : 我的构建脚本使用了Cobertura作为依据代码覆盖指令产生类文件的容器。当JUnit测试运行时，Cobertura 监测代码覆盖范围并且在测试完成后生成一个覆盖率报告。此选项表明Hudson Cobertura已经安装。它指示Hudson检索已确定的Cobertura XML 覆盖率报告，汇总它们到当前作业的Cobertura历史趋势中并且暴露到当前作业的主页上。标题为“Coverage Metric Targets”的选项表明在Hudson获取关于当前作业的状态时，允许你通过指定代码覆盖地图中的覆盖程度来影响最终的测定。(更多信息请查阅关于题为"作业状态"这一节)
图19. 作业示例, 第六部分
Ha！总算到这一点了，如果您已经确认了这个新的作业，现在就运行它吧，看看它是怎么工作的。不管您是如何配置您的构建触发步骤，您都能够随时请求一次特定的构建(总之，随需应变)，除非您选择了Disable Build
。当您打算建立一个新的构建作业，或者调试像我上面描述的这些截图，如果没有等到构建触发器讲完是没有什么意义的
。在下一节中，我将告诉您如何请求一次特别的构建，以及观察它到底是如何运行作业的。