我发现Jenkins共享(Groovy)库名称有点混乱和讽刺,因为我发现Jenkins会为每个构建克隆共享库存储库,是的,为每个执行克隆相同的代码。
这与共享库的概念相反:因为这些都是由多个消费者加载的代码片段。想象一下,如果当你试图加载任何加载的库时,操作系统会制作一个副本,那会是什么样子...(是的,每天数千个)
有没有办法避免这种严重的资源超载?
参考编号:
我发现Jenkins共享(Groovy)库名称有点混乱和讽刺,因为我发现Jenkins会为每个构建克隆共享库存储库,是的,为每个执行克隆相同的代码。
这与共享库的概念相反:因为这些都是由多个消费者加载的代码片段。想象一下,如果当你试图加载任何加载的库时,操作系统会制作一个副本,那会是什么样子...(是的,每天数千个)
有没有办法避免这种严重的资源超载?
参考编号:
2条答案
按热度按时间falq053o1#
我认为目前没有办法避免这一点,但我同意这将是一个巨大的好处。
Jenkins应该缓存共享库,并且只提取
Jenkinsfile
中引用的最新分支。本地缓存的共享库的另一个好处,除了节省不断克隆的开销之外,是独立于仓库的。Jenkins应该能够使用它缓存的最后一个共享库版本--即使仓库关闭了。目前,如果你有不仅构建而且部署的管道,那么你的部署过程就取决于你的共享库仓库的可用性--但是理想的情况是,即使git仓库关闭了,你也可以部署已经构建好的包。
vohkndzv2#
此功能现已通过https://issues.jenkins.io/browse/JENKINS-38992提供
https://github.com/jenkinsci/workflow-cps-global-lib-plugin/releases插件的2.21(及以上)版本已经修复了这个问题,可以在2021年末的最新稳定版本和LTS版本中找到。
在全局设置中声明全局管道库时,您可以使用新字段来启用每个库的缓存。此外,您还可以指定不进行缓存的版本(即分支)。
如果使用JCasC,则可以使用以下语法: