使用 Jenkins/Hudson 自动工具检测?

发布于 2024-11-18 03:42:23 字数 515 浏览 1 评论 0原文

Jenkins/Hudson 中存在哪些机制来自动检测节点上安装的工具?

例如,.NET 框架、Visual Studio 版本、Setup-Builder Tools、已安装的脚本语言可执行文件等

。我目前正在尝试弄清楚 Jenkins 是否以及如何(以及是否有意义)可以自动检测我必须安装在所有节点(Salves)上的工具。

由于我们的节点是 Windows 机器,因此硬编码路径没有意义(恕我直言),因为 Windows 64 位与 32 位/XP 与 Windows 7/不同语言版本的路径不匹配。

此外,相当多的工具需要安装,因此仅镜像文件也不是一个选择。

显然,我可以为我们的工具定义一组环境变量并使用 Jenkins 中的这些变量。但我更愿意使用/构建一些可以自动配置新节点/从站的东西。

您也可以将这个问题解读为:是否可以编写一个插件来自动检测 Windows 从站上的“东西”并使其可以作为节点属性使用?(如果我想这样做,我应该从哪里开始?)

What mechanisms exists in Jenkins/Hudson to automatically detect tools that are installed on the Nodes?

For example, .NET frameworks, Visual Studio versions, Setup-Builder Tools, installed scripting language executables, etc.

I'm currently trying to figure out if and how (and whether it makes sense) Jenkins can auto-detect our tools that I have to install on all the Nodes (Salves).

Since our Nodes are Windows machines, hard-coding paths doesn't make sense (IMHO) due to path mismatch Windows 64bit vs. 32bit / XP vs. Windows 7 / different language versions.

Also, quite a few tools require installation, so just mirroring over files isn't an option either.

Obviously, I could just define a set of environment variables for our tools and use these from Jenkins. But I much rather use/build something that makes new Nodes/Slaves auto-configured.

You can also read this question as: Is it possible to write a plugin that automatically detects "stuff" on Windows slaves and makes that available as Node Properties? (and where would I start if I wanted to do that?)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

孤城病女 2024-11-25 03:42:23

AFAIK,Jenkins 可以本地自动配置的唯一工具是 Java JDK、Ant 和 Maven。我不确定其他插件可以做什么。

您可能必须采用环境变量的方式,或者您可以创建一个多配置作业,将您的工具安装到从属设备上(如果它们尚不存在)。这假设您的工具可以执行安静安装,并且您可以指定安装目录(在所有平台上都相同)。

AFAIK, the only tools that Jenkins can natively autoconfigure are Java JDK, Ant, and Maven. I'm not sure what other plugins can do.

You might have to go the environment variables way, or you could create a multi-configuration job that installs your tools onto the slaves, if they don't already exist. This would assume that your tools can do quiet installs, and that you can specify the installation directory (same across all platforms).

迷爱 2024-11-25 03:42:23

我采用了为所有节点提供一组公共环境变量的路线。
由于无论如何我都必须手动管理 Windows 节点上安装的内容(许多工具都有我需要在使用它们之前运行的安装程序),所以调整每个节点上的环境变量并不是什么大问题。 (我有一个小批处理脚本,可以通过 setx 设置所有内容。)

I've gone with the route of having a set of common environment variables for all nodes.
Since I have to manage what is installed on the Windows nodes manually anyway -- many tools have installers I need to run prior to using them -- adjusting the environment variables on each node isn't such a big deal. (I have a small batch script that set's up everything via setx.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文