Jenkins 工作中的工作继承答案

【问题标题】：Job inheritance in Jenkins jobsJenkins 工作中的工作继承
【发布时间】：2011-09-26 08:05:49
【问题描述】：

您如何处理将 Jenkins 作业映射到您的构建过程，您是否能够在继承时构建级联配置？

对于任何给定的构建，我将至少有三个工作（标准持续集成/夜间、安全扫描、覆盖），然后是一些下游集成测试工作。配置切片器插件处理跨作业的某些方面，但每个作业仍然是非常独立的实体，与其组中的其他作业没有关系。

我最近看到了 QuickBuild，它具有作业继承，其中父作业可以定义一组标准步骤，其子作业可以覆盖和专门化。使用 Jenkins，我有工作副本，这很好，直到我需要更改某些内容。借助 QuickBuild，工作之间的关系让我可以毫不费力地传播我的更改。

我一直试图弄清楚如何在 Jenkins 中处理这个问题。我可以使用参数化构建触发器插件来允许作业调用其他人并覆盖方面。然后我会从被调用的作业中收集数据给它的调用者。我怀疑我会遇到一系列问题，其中有些方面我无法覆盖，这将迫使我在自己的脚本中实现 Jenkins 功能，从而降低 Jenkins 的用处。

您如何在 Jenkins 中处理构建作业的复杂性？您听说过 QuickBuild 的任何严重问题吗？

【问题讨论】：

我今天一直在研究这些问题，尽管对 QuickBuild 没有任何兴趣。特别是我想要 CI 和 Nightly 构建的不同配置选项，例如签出干净的工作空间与执行还原+更新，构建工件的存储时间，以及如何存档或部署工件——同时保持相同的列表为每个构建说明。 Matrix/multiconfig 插件没有提供足够的选项。我认为我们可以通过仅执行构建本身的子作业来管理它，使用参数化工作区调用 - 但它增加了复杂性。
如果您的每项工作都执行 CI 的一个方面，那么工作之间就不需要有任何重复的任务。我们有一个构建作业，它有一个下游作业，它分阶段运行集成测试。如果希望定期运行其中一些分阶段测试，也可以在这些作业中将其设置为定时触发器。这样构建工作只是构建，测试工作只是进行测试等等。如果您使用“克隆工作空间的存档”任务，则下游作业可以访问构建工件。如果您愿意，可以扩展答案吗？
我想知道一年后你是否找到了解决这个问题的办法。
如果我想从 Pipeline 继承（如果可能的话），你有什么建议我将如何使用继承插件或模板插件？
@GuyAvraham 请查看我的回答（关于这个问题的最后一个），详细了解如何通过设计回避继承问题。那个插件我没试过，因为目前我没有那个需求，

标签： build jenkins continuous-integration quickbuild

【解决方案1】：

我想向您指出一个插件的发布，该插件是我的团队开发的，并且最近才以开源方式发布。它实现了完整的“作业之间的继承”。

这里有更多可能对您有帮助的链接：

【讨论】：

有继续开发的计划吗？特别是修复列出的与Job Config History 和Artifactory 的不兼容性。 GitHub 上的最后一次提交是从 2015 年 2 月开始。
也可以通过plugins.jenkins.io/project-inheritance获得

【解决方案2】：

我遇到了几乎同样的问题。我们有一组工作需要为我们的主干以及至少两个分支运行。分支代表我们的版本，每隔几个月就会创建一个新分支。手动创建新工作是没有办法的，所以我检查了一些可能性。

一种可能性是使用template plugin。这使您可以创建一种工作的层次结构。它为构建器、发布者和 SCM 设置提供继承。可能对某些人有用，对我来说还不够。

我检查的第二件事是用于作业克隆的Ant Script，以及他的兄弟Bash Script。这些真的很棒。这个想法是让脚本创建一个新作业，从模板作业复制所有设置，根据需要进行更改。由于这是一个脚本，它非常灵活，你可以用它做很多事情。唯一的缺点是，这不会产生真正的层次结构，因此模板作业中的更改不会反映已克隆的作业，只会反映将要创建的作业。

看看这两种解决方案的优缺点，两者结合可能效果最好。您创建一个模板项目，其中包含一些适用于所有作业的基本设置，然后使用 bash 或 ant 脚本根据该模板创建作业。

希望对您有所帮助。

【讨论】：

模板插件是要走的路。我们一直在使用它，它完成了我们真正想要的模板插件！

【解决方案3】：

有人问我，我们对这个问题的最终解决方案是什么... 经过数月与我们的采购系统的斗争，我们在 Quickbuild 上花费了大约 4000 美元。在大约 2-3 个月的时间里，我们有了一个模板化的构建系统，并且对它非常满意。在我离开公司之前，我们的系统中有几个产品组，并且也在自动化发布过程。

Quickbuild 是一款很棒的产品。它应该在 $40k 级别，但它的价格要低得多。虽然我确信 Jenkins 可以做到这一点，但它会有点麻烦，而 Quickbuild 已经内置了这个功能。我之前在产品之上实现了复杂的行为（例如 SVN 1.0 中的合并跟踪）并且后悔了。 Quickbuild 价格合理，为我们的构建和测试系统提供了坚实的基础。

目前，我在一家使用 Bamboo 的公司，希望它的新功能分支功能能够提供 Quickbuild 可以做的大部分事情

【讨论】：

【解决方案4】：

EZ Templates 插件允许您将任何作业用作其他作业的模板。真是太棒了。您只需将基础作业设置为模板：

* 通常你也会禁用基础作业（比如“抽象类”）。

然后创建一个新作业，将其设置为使用基本作业模板，然后保存：

现在编辑新工作 - 它将包括所有内容！（并且您可以覆盖现有配置）。

注意：还有另一个插件Template Project 用于配置模板，但最近没有更新（最后一次提交是在 2016 年）。

【讨论】：

【解决方案5】：

我们使用 quickbuild，它似乎对大多数事情都很有效。我什至可以使用他们的 API 来编写自定义插件。缺乏快速构建的一个领域是声纳集成。声纳团队有一个 Jenkins 插件，而不是一个用于快速构建的插件。

【讨论】：

【解决方案6】：

鉴于目标是 DRY（不要重复自己），我目前赞成这种方法：

使用jenkins shared library 和jenkins pipeline unit 来支持TDD
使用 docker 镜像，使用 groovy/python 或任何您喜欢的语言来执行需要 api 等的复杂操作
保持实际的作业管道非常简洁（基本上只是为了拉取构建参数并将它们传递给共享库中的函数，这些函数可能使用 docker 图像来完成工作。

这非常有效，消除了复杂构建作业的 DRY 问题。

共享管道 Docker 代码示例 - vars/releasePipeline.groovy

/**
 * Run image
 * @param closure to run within image
 * @return result from execution
 */
def runRelengPipelineEphemeralDocker(closure) {

    def result

    artifactory.withArtifactoryEnvAuth {
        docker.withRegistry("https://${getDockerRegistry()}", 'docker-creds-id') {
            docker.image(getReleasePipelineImage()).inside {
                result = closure()
            }
        }
    }
    return result
}

使用示例

图书馆“我的共享詹金斯图书馆”

releasePipeline.runRelengPipelineEphemeralDocker {
    println "Running ${pythonScript}"
    def command = "${pythonInterpreter} -u ${pythonScript} --cluster=${options.clusterName}"
    sh command
}

【讨论】：