时间戳

首页 > 解决方案 > 使用一个 Jenkinsfile 或多个 Jenkinsfile

jenkins - 使用一个 Jenkinsfile 或多个 Jenkinsfile

问题描述

我们目前正在使用 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。它确实有点帮助，因为它为您提供了一些转换的步骤，但无法转换所有步骤，并且会在管道脚本中给出注释“//无法转换参考的构建步骤...请验证并在需要时手动转换。” 有一个选项“递归转换下游作业（如果有）”，如果您选择该选项，它似乎会将所有下游作业添加到同一个管道脚本中，并且确实混淆了作业参数。还有一个“提交 JenkinsFile”选项。我会再玩一些，但这并不是转换为管道的全部和结束，我仍然不确定我是否应该拥有一个或多个脚本。

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

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

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

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

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

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

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

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

2019 年 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”...图片1

图片2

图3

Image4e

为什么这样做？

标签： jenkinsjenkins-pipeline

解决方案

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

总的来说，我会说范式转变主要集中在将旧工作转换为阶段，以便自动化构建过程。如果您有半/全自动 CI/CD 流程，这可能看起来像

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

推荐阅读