在一个Jenkins文件中,无论如何要使共享库版本可编程?

1sbrub3j  于 2023-10-17  发布在  Jenkins
关注(0)|答案(1)|浏览(109)

我通常在使用共享库时这样做,在我的Jenkinsfile.中,

@Library("[email protected]") _
...

但每次更新共享库时,我都会使用语义版本控制相应地更新版本。例如,对于bug修复,我更新到版本2.0.1,对于破坏性更改,我更新到版本3.0.0
因此,对于使用我的共享库的模块,我需要创建一个Bitbucket pull请求,以相应地更新它们各自Jenkinsfile s中的版本。有没有一个好的方法来规避这一点,通过使用一个变量,也许设置版本?谢谢

kkbh8khc

kkbh8khc1#

为了回答你的问题,是的,你可以让你的库名称动态根据官方文档在这里。检查下面的例子,我从输入参数中阅读库版本。

properties([parameters([string(name: 'VERSION', defaultValue: '2.0.0')])])
library "my-shared-lib@${params.VERSION}"

所以你可以用任何逻辑来决定你想要使用的版本。
话虽如此,我认为更好的方法是采用分支和标记策略,然后让您的子团队根据各个团队的风险偏好决定他们喜欢采用什么。例如,考虑以下情况。

默认分支(例如:main/master):这个分支有最新的代码,无论你做了一个破坏性的更改还是一个bug修复,这个分支都将有最新的更改。因此,这可以是共享库的默认分支,也可以作为@Library("my-shared-lib@main")使用
主版本分支:当你决定发布一个主要版本时,比如3.0.0,你可以创建一个分支branch-3.x,它将包含你为3.0.0所做的所有bug修复。想要获取最新补丁的用户可以使用这个分支@Library(" [[email protected]](https://stackoverflow.com/cdn-cgi/l/email-protection) ")
具体标签:对于不想自动提取更改的团队。您可以继续使用相同的标记策略。当你修复了3.0.0的bug后,你可以发布3.0.x,任何想要采用这些修复的人都必须更新他们的Jenkins文件。

相关问题