使用一个 Jenkinsfile 或多个 Jenkinsfile答案

【问题标题】：Use one Jenkinsfile or multiple Jenkinfiles使用一个 Jenkinsfile 或多个 Jenkinsfile
【发布时间】：2019-07-17 14:20:56
【问题描述】：

我们目前正在使用 Windows \ Jenkins 2.107.1（无管道），我正在研究管道。我们有一个夜间构建作业，它从存储库中获取，并提交并等待其他作业。我看到 9 个作业同时在同一个主节点上运行（我们只有一个主节点）。我不清楚我们是否应该拥有一个 Jenkinsfile 或多个 Jenkinsfile。它不会是多分支管道，因为我们不会创建测试分支然后合并回主分支。在存储库中，我们有 product1.0 分支、product2.0 分支等，并且只构建了一个分支（最新的一个）。虽然我确实喜欢 Blue Ocean 编辑器，但它仅适用于 MultiBranch 管道。

我是将所有作业合并到一个 Jenkinsfile 中，还是为每个现有作业（Jenkinsfilestart、JenkinsfileFetchCVs、JenkinsFileFetchGit、Jenkinsfilenextjob 等，然后一个调用另一个）创建多个 jenkins 文件？我是否将所有旧作业创建为 Jenkinsfile 或由一个主 Jenkinsfile 执行的脚本？我是在声明式还是脚本中执行此操作？

已在测试 VM 上设置 Jenkins 管道，但尚不清楚要走哪条路。

寻找方向和\或示例。是否有关于如何转换现有 Jenkins 非流水线系统的文档？

我在完成初始帖子后发现了这个...https://wiki.jenkins.io/display/JENKINS/Convert+To+Pipeline+Plugin。它确实有点帮助，因为它为您提供了一些转换的步骤，但无法转换所有步骤，并且将在管道脚本中提供 cmets "//无法转换参考的构建步骤...请验证并在需要时手动转换。”有一个选项“递归转换下游作业（如果有）”，如果您选择该选项，它似乎会将所有下游作业添加到同一个管道脚本中，并且确实混淆了作业参数。还有一个“提交 JenkinsFile”选项。我会再玩一些，但这并不是转换为管道的全部和结束，我仍然不确定我是否应该拥有一个或多个脚本。

于 2019 年 7 月 26 日添加 - 让我们看看我的研究是否正确……

声明式管道（来自 SCM 的管道脚本）存储在存储库中的 Jenkinsfile 中。每次执行此 Jenkins 作业时，都会从存储库中获取一次（以获取最新版本的 Jenkinsfile）。

Pipeline 脚本作为 config.xml 文件的一部分存储在 Jenkins\Jobs 文件夹中（它不存储在存储库中，也未存储在作业文件夹中的单独 Jenkinsfile 中）。仅当作业需要时才会从存储库中提取（您不需要执行存储库提取来获取管道脚本）。

除了我们的夜间产品构建之外，我们还有其他工作。我可以为每个其他作业创建一个单独的声明性 Jenkinsfile（JenkinsfileA、JenkinsfileB 等），然后也存储在存储库中（与主 Jenkinsfile 在同一分支中），但这意味着每个在这些额外的作业中，为了获得该作业的特定 Jenkinsfile，还需要进行存储库获取（基本上为每个作业获取\克隆存储库分支，并且将存储库分支的多个版本不必要地下载到每个作业的工作区)。

这对我来说没有意义（除非我对迄今为止的事情的理解不正确）。因为主要产品构建确实需要在每次运行时获取（以获取任何可能的开发人员签入），所以我认为为该工作执行声明性 Jenkinsfile 没有问题。对于其他作业（如果我们暂时不离开经典（非管道）格式），它们将是管道脚本。

是否有任何方法（或计划）能够执行声明式管道，而不必每次都存储在存储库中并进行提取（减少成为 Groovy 开发人员的需要）？ Blue Ocean 脚本编辑器似乎是一种更容易用于创建管道脚本的工具，但它仅适用于 MultiBranch 管道（我们不这样做）。

序列化（重新启动作业），是否仅适用于节点关闭时，或者如果管道作业失败，您可以从任何点重新启动管道作业（声明式或脚本式）？

我看到有一些地方可以查看 Jenkins 插件已被移植到管道中，但是有什么可以运行来查看您拥有的经典作业，以确定哪些作业正在执行转换为管道时遇到问题？

19 年 8 月 2 日... 学习和玩管道。我看到您可以在 Pipeline Scrip 窗口中使用声明式，但它仍将其存储在 config.xml 文件中。而且我在同一个脚本中使用了声明式和非声明式的组合。

我正在尝试理解 Blue Ocean 界面，“MultiBranch”这个词让我有点吃惊。我们不创建测试分支，它们将它们合并回主分支。在存储库中，我们为产品的每个版本都有分支，我们很少回到以前的分支\版本。那么，如果我现在正在使用 branchV9，我是否还需要在 Master 分支或任何其他以前版本的分支中使用 Jenkinsfile？

我一直在玩 Blue Ocean（它只适用于 MultiBranch 管道）。我在 Windows 系统 Jenkins 2.176.2 上，并且拥有截至今天 (1.18.0) 的所有最新蓝海插件。我正在访问本地 Git 存储库（不是 GitHub），并且正在运行以下内容...

如果我尝试使用“c:\GitRepos\Pipelines1.git”，我会得到“not a valid name”...

为什么要这样做？

【问题讨论】：

标签： jenkins jenkins-pipeline

【解决方案1】：

如果您有一个作业要在多个分支上执行（可能有可选的阶段，取决于分支名称或标签或其他），那么您仍然可以使用多分支管道。

一般来说，我会说范式转换主要关注将旧作业转换为阶段，以自动化您的构建过程。如果您有半/全自动 CI/CD 流程，这可能看起来像

具有以下阶段的多分支管道项目（所有分支）（第一个 jenkinsfile）
- 构建（所有分支）
- 单元测试（所有分支）发布报告
- 发布工件（主分支和发布分支）
- 构建和发布 docker（主分支和发布分支）
- 部署到测试（主分支和发布分支）
- 运行集成测试（主分支和发布分支）
- 如果部署结果符合预期，部署到暂存（主分支和发布分支）可能以手动步骤结束
- 部署到生产（发布分支）
夜间测试的管道作业（其他 jenkinsfile），这里的结果是什么？它会破坏 CI/CD 流程吗？

【讨论】：

我在帖子中声明这不会是 MultiBranch。存储库中的每个分支都用于产品的单独版本，我们很少构建以前的版本。
好吧，我无意让你改变主意。只是描述我如何将整个管道理解为代码和 jenkinsfiles。让多个管道作业指向一个 jenkinsfile 的想法很有趣。我想知道是否有用例。
如果我正确理解您的评论，听起来您是在说，如果您有一个执行其他作业的经典 Jenkins 作业，通常在转换为管道时，所有这些下游作业都被合并进入唯一的 Jenkinsfile。
不，我是说你可以有一种新的工作类型——管道，就在詹金斯。在单个 jenkinsfile 中累积更多这些文件或将其绑定到项目特定分支上的 jenkinsfile 是没有意义的。有模板、构建过程自动化等想法。这一切都应该以某种方式联系起来。例如，我假设您描述的这个下游作业被其他几个作业/分支/项目重用。