构建流程与构建管道

Question

我正在尝试使用 Build Flow 插件拆分几个 Jenkins 作业，以便我们拥有三个“起点”，而不是三个整体作业，然后使用 DSL 触发下游作业。我选择了 Build Flow 而不是 Build Pipeline 插件，因为在不同的管道之间共享作业似乎要困难得多（即，通过单个编译作业共享多个启动作业的工作区）。

之前，我设置了三个工作：Project-PR、Project-DEV 和 Project-PROD。

只要在 GitHub 中发生拉取请求，Project-PR 就会构建，并且只运行我们单元测试的一小部分，以便我们可以快速验证 PR 是否可以合并。

只要将 GitHub 中的功能分支合并到主开发分支中，Project-DEV 就会构建，并且能够手动触发并提供不同的分支来拉取。它将运行全套单元——基本上是一个健全的检查，一切仍然很好。然后它将编译和缩小，并推送到 QA 环境进行测试，然后它将针对该 QA 环境运行全套集成测试。此步骤被配置为参数化构建，参数是要拉取、测试和推送的分支的名称。它将推送并设置特定于该分支的 QA 环境，以便我们可以对多个功能进行 QA，而无需合并到开发中（即 feature-one.qa.example.com、feature-two.qa.example.com ） .

Project-PROD 只能手动触发，并且会执行完整的单元和集成测试套件，编译和缩小前端代码（Less、JS 和 CSS），并将构建的代码推送到特殊的“在 GitHub 中发布分支”，然后可以部署——我们还没有完全达到 Jenkins 负责部署的地步。

现在，我想要设置的是将子任务拆分为它们自己的作业，这样就可以轻松设置新作业，而无需复制和粘贴所有构建步骤（或复制作业和改变所有需要独特的东西）。这将让我们做一些事情，比如创建 Project-DEV 的副本，但将最后一项工作切换到部署到云中设置的暂存环境的工作。或者轻松地创建一个可以将测试结果报告给第三方来源的作业，即将结果复制到共享网络文件夹或其他东西。或任何数量的东西。目标基本上是使用这些子任务作业作为构建块，让我们构建更复杂的作业，同时也更容易更新构建的一部分的工作方式（例如，也许我们切换到不同的编译技术，这可能更改 Jenkins 编译代码的方式）。

例如，Project-PR 将被拆分为以下内容：

Project-PULL -> Project-SetupBuildEnv -> Project-PartialUnitTests
(BuildFlow)     (Normal Job)             (Normal Job)        

SetupBuildEnv 只会拉下任何 NPM 或 Composer 要求，并设置测试和构建所需的目录。然后 PartialUnitTests 运行，并将其结果报告给

Project-DEV 可以这样拆分：

Project-DEV -> Project->SetupBuildEnv -> Project-FullUnitTests  -> Project-Compile -> Project-Minify -> Project-DeployQA -> Project-FullIntegrationTests

这样，共享的构建过程部分（在本例中为 Project-SetupBuildEnv ）可以轻松地在作业之间共享，减少重复，并且更容易更新构建过程中的步骤而无需记住使用该步骤的每个作业。

现在，我正在使用Shared Workspace 插件，以便所有步骤都使用相同的工作区。但是，我遇到了一个问题：它实际上并没有使用一个工作区。正在发生的事情是 Build Flow 作业将获得一个目录（例如：/sharedspace/shared_one），然后从 GitHub 下载代码到那里。然后它将触发 DSL，从而启动“SetupBuildEnv”作业。但它不会在同一个目录中工作，而是会获得一个名称如“/sharedspace/shared_one@2”的目录，并在其中运行构建设置任务。然后当它进行第三步（单元测试）时，它失败了，因为现在它有了第三个目录（ /​​sharedspace/shared_one@3 ），但是那个目录没有运行设置，所以需要节点和作曲家模块丢失。奇怪的是，共享工作区插件看起来像是将第一个共享工作区复制到另一个目录并增加一个计数器（目录名称的 @N 部分）并将其提供给其他工作。

所以，提问时间：

1. 有没有办法修复 Shared Workspace 插件，使其实际上只为每个作业使用一个目录？
2. 如果没有，是否可以让 Clone Workspace 插件接受参数，以便我可以指定要使用的存档工作区而不是使用下拉菜单？
3. 另一种可能性：将使用共享工作区插件，但使用高级 git 作业选项中的“本地子目录 for repo（可选）”选项来指定要使用的目录？
4. 如果这一切都失败了，是否有其他方法可以设置构建管道，以便与我错过的其他管道共享作业？

Answer 1

根据我的经验，即使您确实让这项工作发挥作用，这也可能不是一种长期可扩展的方式。我们发现共享工作区插件对于长/复杂的构建完全是一个坏主意（与您的原因类似 - 但也：跨数十个从站扩展变得突然变得困难）。可以说，这个想法有点违背现代可扩展 CI 的精神。

相反，我会将更多内容委托给您的构建工具，无论是 Maven / Gradle、Ant，甚至是 Grunt，等等。如果您想保持这些构建真正模块化，但不能在每一步都重建（我们认为完全独立值得在每个构建中浪费几分钟），那么也许考虑在关键阶段创建有用的人工制品 - 在您的情况下，缩小资产 TAR、库 JAR 或 webjars 或其他任何东西，并将 它们 部署到（Maven？）存储库。

管道中的后续构建步骤可以快速、轻松且可重复地从该集中式存储库中提取最新（或命名版本）资产，并继续构建过程。

另一种方法（有相似之处）是构建一个或多个资产，但只有在运行越来越多的测试后才能提升它们，这可以在由构建流程协调的单独构建中完成，使用Promoted Builds plugin 等