Question

我们的团队与其他团队共享Jenkins服务器，这意味着我们正在共享相同的操作系统级构建用户帐户。不同团队的操作系统级构建用户设置（Maven设置，bash设置，用户级Ant库等）已经碰撞了几次 - “修复”一个团队的工作设置无意中“打破”另一个团队的工作。我遇到的最简单的解决方案是为每个团队提供自己的操作系统级构建用户帐户，以便执行其Jenkins工作 - 但我找不到办法做到这一点。

我已经与Google核实了，而且还在这里

https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins

在这里

https://wiki.jenkins-ci.org/display/JENKINS/Plugins

无济于事。

有办法做到这一点吗？如果没有，你能推荐任何最佳实践来隔离彼此的构建集吗？

Answer 1

Maven Specific

您可以想到两个选项，

将额外的Maven安装添加到Jenkins全局配置中，每个安装都使用自己的主目录，从而使用设置文件。这将允许您使用完全不同版本的Maven，并根据作业要求进行选择（您可以选择选择要在作业中使用的maven的“版本”。
与（1）类似，但使用Maven命令行参数指定特定设置配置。它不那么“明显”但可能更快实施

多从属

您可以在每台计算机上使用多个从站。它非常显着地增加了构建的开销，并且实现使得您在计算机上拥有多个用户帐户，每个用户帐户根据需要进行设置，然后为每个用户设置一个从属实例。

我不确定这些解决方案是否能完全解决您的问题，我会思考并看看是否还有其他问题，但它可能会给出一些起点

Answer 2

密钥构建到包含该团队设置的特定团队目录。例如，为每个构建提供一个参数'TEAM'，将其默认值设置为相应的团队名称，并将该参数用作包含团队设置的目录的键（因此，而不是使用$ {HOME}你想做的，你会用$ {TEAM_SETTINGS} / $ {TEAM}）。

Answer 3

您可以设置每个作业用户（有权访问/可以构建特定作业的用户）。

在“管理Jenkins”下＆gt; “配置系统”＆gt;

点击启用安全性
检查基于项目的矩阵授权策略

但是，我不认为单个作业有“per-build”选项。

如果您拥有团队之间共享的相同项目，则可以（并且可能应该）为此项目创建两个作业，并且每个作业都使用不同的库/脚本。

您还可以参数化构建（在作业页面上，“配置”＆gt; 此构建参数化）并通过字符串参数提供库版本等。

您还可以使用参数作为团队名称，并在构建脚本中根据参数更改库：

例如，有一个名为“TEAM”的参数，带有选项：TEAM_A和TEAM_B，并且在你的脚本中有

if [ $TEAM == "TEAM_A" ]
then
  ANT_HOME=/opt/ant/libA
else
  ANT_HOME=/opt/ant/libB
fi

<强> ============================================ ==========================

您是否考虑过采购设置？在Linux中，您可以通过在脚本文件中保存操作系统设置（例如路径等），并在Windows中使用source /path/to/settings/file来call /path/to/settings/batch/file来完成此操作。

您能举例说明您需要和每个构建用户的操作系统级别设置吗？

Answer 4

你的问题很常见。

每当构建服务器上安装了非标准内容时，某些内容就会中断。

我所知道的唯一解决方案是

为每个团队或产品设置单独的构建从属。然后他们可以在构建奴隶上安装他们想要的任何东西，他们创造的任何混乱都是他们自己的错。
作业所需的任何依赖项都需要与作业一起提供。这是我的首选工作方式。例如：如果作业需要库或工具，则库或工具不会安装在构建服务器上，而是安装在源树中，构建将使用源树中的库。

有时后一种方式更有效。您需要设置工具或库，以便在源树中安装它时可以正常工作。有些工具有硬编码路径，但它们不起作用。在这种情况下，您可以安装工具的源代码并在构建期间编译该工具。

更好的解决方案是为所有工具和库设置单独的Jenkins作业，需要库或工具的作业将从Jenkins作业下载它们。

通过这种方式，您可以控制所有依赖项，并且不同的作业不会发生冲突，例如一个需要较旧版本的库，一个需要较新版本。如果有人升级了库，那么在版本控件中可以立即看到它，它会做什么。

我可以在每个作业的基础上指定操作系统级别的构建用户吗？

4 个答案:

Maven Specific

多从属