限制Jenkins共享主

Question

我不确定我是否在标题中对此进行了总结，因此欢迎提出建议。

Jenkins配置：

• 一个有0个执行器的Jenkins linux master。
• 许多不同的代理/代理执行者。
• 许多声明性管道作业，主要是脚本化阶段。
• 声明性管道指定agent { label "some-label" }
• 使用git作为VCS加载许多可信共享库（在主Jenkins配置中配置的库）。
• 上面的大多数共享库都是有意加载而不是显式加载。

假设： 当隐式加载共享库时，它们总是克隆在主服务器上，并且在执行实际管道代码之前将脚本加载到内存中。

问题： 对于每个运行的管道，在任何管道代码可以序列化并在代理上运行之前，会在主服务器上克隆X个可信共享库。 我无法知道您可以告诉Jenkins只能立即在主服务器上运行N个克隆。最终的结果是，当许多管道同时运行时，同时在主服务器上运行的git克隆数量很大，这会使Jenkins服务器或git服务器崩溃并导致构建失败（或者由于超时或其他相关原因）。

解决方法（排序） 隐式加载尽可能少的可信共享库，然后在Lockable Resources Plugin中包含lock ... { }时显式加载它们以限制git克隆的数量。 这并没有真正解决这个问题，因为有特定的原因你需要使用隐式加载vs显式。

希望我遗漏了一些明显的东西：）

Answer 1

当然我的建议是有意见的。

以下物品导致我的眉毛抬起：

  

许多受信任的共享库（在Jenkins主配置中配置的那些共享库）都是使用git作为VCS加载的。

鉴于这张票是开放的，只有很少的评论/投票： https://issues.jenkins-ci.org/browse/JENKINS-48210，

詹金斯社区并不吸引许多人。

我认为jenkins网站上有关库的文档， 有一些隐藏的假设：

1. SHARED 库只有在其代码用于多个作业中（即减少代码重复）时才有意义。您可能会通过将每个作业的代码包装到伪“共享”库代码中来滥用该想法，这是对术语IMHO的滥用
2. 您不能通过网络来推动或拉动网络；）

那么，您可以推断出什么是实用的AI：

1. 升级硬件：最便宜的解决方案（考虑开发人员的小时费率与硬件成本）是购买更好的NIC或提升功能更强大的VM并为其分配更多的吞吐量
2. 我将回顾您如何构建共享库。将共享代码放在一个带有多个类的快乐库中，这将使每个构建版本的git流量减少到1个。

另外，也很高兴知道一些有关CI网络和git服务器之间的链接速度以及并行运行[O（？）]的作业的信息。

请告诉我您如何解决问题。 （听起来很有趣，我想学习更多！）