Pet*_*ahn 19 continuous-integration build jenkins quickbuild
你如何处理Jenkins作业到你的构建过程的映射,你是否能够在继承中构建级联配置？
对于任何给定的构建,我将至少有三个作业(标准的持续集成/夜间,安全扫描,覆盖),然后是一些下游集成测试作业.配置切片器插件处理交叉作业的某些方面,但每个作业仍然是它自己的单独实体,与其组中的其他作业无关.
我最近看到了QuickBuild并且它具有作业继承,其中父作业可以定义一组标准步骤,其子代可以覆盖和专门化.有詹金斯,我有工作的副本,这是好的,直到我需要改变一些东西.使用QuickBuild,作业之间的关系可以让我轻松地传播我的更改.
我一直试图弄清楚如何在詹金斯处理这个问题.我可以使用参数化构建触发器插件来允许作业调用其他人并覆盖方面.然后,我将从被叫作业中的数据收集到其调用者.我怀疑我会遇到一系列问题,其中有些方面我无法覆盖,这将迫使我在我自己的脚本中实现Jenkins功能,从而使Jenkins不那么有用.
你如何处理詹金斯的构建工作的复杂性？您是否听说过QuickBuild存在任何严重问题？
小智 13
我想向您指出我的团队已经开发并且最近才在开源下发布的插件的发布.它实现了完整的"作业之间的继承".
这里有进一步的链接,可能会帮助您:
我有几乎同样的问题。我们有一组工作需要为我们的主干以及至少两个分支运行。分支代表我们的版本，每隔几个月就会创建一个新分支。手动创建新工作并不是解决方案，所以我检查了一些可能性。
一种可能性是使用模板插件。这使您可以创建某种工作的层次结构。它为构建者、发布者和 SCM 设置提供继承。可能对某些人有用，但对我来说还不够。
我检查的第二件事是用于作业克隆的Ant 脚本，以及他的兄弟Bash 脚本。这些确实很棒。这个想法是让脚本创建一个新作业，从模板作业复制所有设置，根据需要进行更改。由于这是一个脚本，因此非常灵活，您可以用它做很多事情。唯一的缺点是，这不会产生真正的层次结构，因此模板作业中的更改不会反映在已经克隆的作业上，只会反映在未来将创建的作业上。
考虑到这两种解决方案的缺点和优点，两者的结合可能效果最好。您创建一个模板项目，其中包含一些适用于所有作业的基本设置，然后使用 bash 或 ant 脚本根据该模板创建作业。
希望有帮助。
| 归档时间： |
|
| 查看次数： |
11173 次 |
| 最近记录： |