当前位置: 代码网 > 服务器>服务器>Linux > Jenkins是构建多平台NUT的方式

Jenkins是构建多平台NUT的方式

2024年08月04日 Linux 我要评论
Jenkins 是多平台构建 NUT 的方式,而 jenkinsfile-dynamatrix 则是找出今天可以构建内容的方式 网络 UPS 工具(NUT)项目即将迎来其成立四分之一个世纪的日子。作为第一个面向 UPS、ePDU、太阳能等设备的开源多供应商电力硬件监控解决方案,它在此领域成为了事实上的标准(最近发布的 RFC 9271 使其成为法律标准)。多年来,它被嵌入到各种服务器和桌面操作系统中,从嵌入式到大型机和 NAS,并且使用了多种工具包和第三方依赖进...

jenkins 是多平台构建 nut 的方式,而 jenkinsfile-dynamatrix 则是找出今天可以构建内容的方式

网络 ups 工具(nut)项目即将迎来其成立四分之一个世纪的日子。作为第一个面向 ups、epdu、太阳能等设备的开源多供应商电力硬件监控解决方案,它在此领域成为了事实上的标准(最近发布的 rfc 9271 使其成为法律标准)。多年来,它被嵌入到各种服务器和桌面操作系统中,从嵌入式到大型机和 nas,并且使用了多种工具包和第三方依赖进行构建。随着演化的推进,警告被消除,功能被添加,代码库仍然预期在过去二十年间发布的任何平台上运行。如果机器及其操作系统仍在运行,现代 nut 也应如此。

作为活跃的社区成员和最终的项目维护者,我的首要目标之一是解决不同实现和版本的工具包在构建过程中发出的数百个编译器警告 —— 因为它们确实提出了有效的关注点,而且这些报告的存在掩盖了贡献引入的新错误的可见性。事实上,有几个大而有用的更改在 pr 队列中等待了数年,因为包括作者在内的没有人对这些更改的可靠性有很好的把握。这个 “fightwarn” 工作花费了几年时间,使用了一个项目内部的 jenkins 农场,以及当时的免费开源软件(foss)travis ci 以及一位团队成员的 buildbot 实例,处理几个 linux 版本和几种 cpu 架构,以覆盖不同的位宽和字节序,以及 gcc 和 llvm clang 的混合。相当多的问题只与某些工具包的代、c 标准修订版、make 或 shell 实现、autotools 版本相关…… 而针对一个平台的修复可能会给另一个平台带来错误。因此,为了保持 nut 在所有地方都能工作,其迭代版本需要定期在所有地方构建。

最终,免费 travis ci 的时代结束了,nut 获得了由 fosshost.org 赞助的 ci 农场的虚拟机,以继续进行多平台测试。使用自定义的 jenkins 实例来处理项目代码库的构建,并利用其他虚拟机中的众多操作系统(作为 ssh 构建代理),以及社区贡献的构建代理(例如 swarm 代理),是自然而然的选择:那时已经开始在 https://github.com/networkupstools/jenkins-dynamatrix 项目上工作。这是一个 jenkins 共享库,它构建了一个类似于标准矩阵构建的巨大并行阶段映射。 然而在这种情况下,并不是矩阵定义完全决定应该构建什么,而是构建代理预期会报告其标签的能力 —— 例如它们运行的平台以及可用于测试的工具包的版本和实现,以及是否可以构建 “所有内容” 或只是某些配置文件(并非所有 os 发行版都提供 nut 可以构建的所有依赖项)。该库还帮助确定根据安装的 gcc 或 clang 版本可以构建哪个 c 或 c++ 语言修订版。每当构建开始时,nut jenkinsfile(jenkins-dynamatrix 库的消费者)可以评估今天可以构建什么 —— 基于当前已知的构建代理群体,从而构建测试矩阵。

这种安排使得 nut 可以在常见免费 ci 平台不提供的多种平台上构建。有可能找到在最新 linux、macos 和 windows 上构建 foss 的方法,有时甚至在非 x86 cpu 上。找到 freebsd、openbsd 或 solaris/illumos 等平台的构建器几乎是不可能的,更不用说比六年前更老的 linux 发行版了。 现在,nut 的每个迭代都经过 gnu、bsd 和 sun make 实现测试,shell 助手由 bash、dash、ksh、busybox 等进行测试,gcc 从早期的 4.x 版本开始,clang 从 3.x 版本到最近发布的第十几个版本,跨越了十几种硬件平台(一些在 qemu 中),以及带有和不带有 gnu 扩展的 c/c++ 标准的几个修订版。总的来说,最近定期连接的构建器大约准备了 150 个阶段(其中一些运行几个内部脚本化的构建场景,所以大约有一千次构建发生)。有时,一个微妙的警告会导致这些场景在 pr 构建期间在这样或那样的操作系统、这样或那样的编译器上发出抱怨。这使我们确信,这样的机制仍然有用,而且任何社区足够关心以贡献构建器的操作系统都得到了完全支持。

在数百次构建成功且没有警告的情况下 —— 可靠地、可重复地,每次都是如此 —— 长期存在的 pr 的闸门被打开。最大的改进包括同时支持 libusb-0.1 和 libusb-1.x(排队等待了 5 年)以及恢复 nut 对 windows 的支持(排队等待了 9 年),自信地合并而未引入警告和回归。这些构建中的绝大多数都在自定义的 “nut ci” 农场进行,由 jenkins 驱动。一些场景在 circleci 和 appveyor 上运行,以利用 macos 和 windows 上的一些免费 foss 构建。 在与 jenkins 社区的显著互动中,这项工作及相关努力导致了 git-client-plugin 的改进,以扩展引用存储库的使用,即时消息插件和 ircbot-plugin 用于通过 irc 服务器查询 jenkins 服务器状态,lockable-resources 插件用于解决这里那里的许多


(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2025  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com