Hudson CI 的自定义报告
我过去的 CI 经验与 CC.Net 紧密结合，但为了创新，我想尝试 Hudson 服务器作为 CI 服务器。 我想知道，是否有可能通过转换在 CI 上运行的各种工具的 XSLT 输出来嵌入构建报告自定义报告？ 例如，我有手工制作的 IIS 日志解析器，它输出 XML，是否可以将其结果包含到构建日志中并在某些条件下构建失败？
My past CI experience is tightly coupled with CC.Net, but for sake of innovations I want to try Hudson server as CI Server.
I wondering, is there a possibility to embed into build report custom reports, by transforming XSLT output of various tools that runs on CI?
For example, I have hand-made IIS Log parser, that outputs XML, is it possible to include it's result into build log and fail build on certain condition?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定您的目标，所以让我以几种不同的方式回答。
要将内容放入构建日志中，只需将数据从构建脚本/进程输出到标准输出即可。您可以深入研究任何单独的构建并查看控制台链接的输出。
为了获得正确的报告，您需要生成 HTML 文档。我相信有一个通用插件可以在页面上提供链接。这可能是你最好的路线。如果您想要带有图标的自定义链接，则需要编写自己的插件。
如果您希望图表显示在项目页面上，您将需要编写自己的插件。
从代码的角度来看，插件架构并不太复杂。然而，Hudson 是使用 Maven 构建的，这意味着您几乎必须使用 Maven 工具集和框架来构建插件。如果您还没有使用过 Maven，那么它可能是 Hudson 插件工作量最大的部分。我希望他们以不需要承担太多知识/经验开销的方式提供类似的 API，但我怀疑在现阶段这将是重大的架构变化。
I'm not sure of your goals, so let me answer a couple of different ways.
To get things into the build log, just output the data to stdout from your build scripts/process. You can dive into any individual build and look at the output from the Console link.
For a proper report, you'll need to generate the HTML document. I believe there is a generic plug-in that provides a link on the page. It's probably your best route. If you want a custom link, with icon, you'll need to write your own plug-in.
If you want graphs to show up on the project pages, you will need to write your own plug-ins.
From a code perspective, the plug-in architecture isn't too complicated. However, Hudson is built with Maven, which means you almost have to use the Maven tool set and framework to build the plug in. Maven, if you haven't used it, is probably the largest part of the Hudson plug in effort. I wish they offered similar APIs in a manner that didn't require taking on so much knowledge/experience overhead, but I suspect that would be significant architectural change at this stage.