我正在尝试使用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 的副本，但将最后一项工作切换到部署到云中设置的暂存环境的工作。或者轻松地创建一个可以将测试结果报告给第三方来源的作业，即将结果复制到共享网络文件夹或其他东西。或任何数量的东西。目标基本上是使用这些子任务作业作为构建块，让我们构建更复杂的作业，同时也更容易更新构建的一部分的工作方式（例如，也许我们切换到不同的编译技术，
例如，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 ）可以在作业之间轻松共享，减少重复，并且更容易更新构建过程中的步骤，而无需记住每个作业使用该步骤。
现在，我正在使用共享工作区插件，以便所有步骤使用相同的工作区。但是，我遇到了一个问题：它实际上并没有使用一个工作区。正在发生的事情是 Build Flow 作业将获得一个目录（例如：/sharedspace/shared_one），然后从 GitHub 下载代码到那里。然后它将触发 DSL，从而启动“SetupBuildEnv”作业。但它不会在同一个目录中工作，而是会获得一个名称如“/sharedspace/shared_one@2”的目录，并在其中运行构建设置任务。然后当它进行第三步（单元测试）时，它失败了，因为现在它有了第三个目录（ /sharedspace/shared_one@3 ），但是那个目录没有运行设置，所以需要节点和作曲家模块丢失。什么'
所以，提问时间：
- 有没有办法修复共享工作区插件，使其实际上只为每个作业使用一个目录？
- 如果没有，是否可以让 Clone Workspace 插件接受参数，以便我可以指定要使用的存档工作区而不是使用下拉列表？
- 另一种可能性：将使用共享工作区插件，但使用高级 git 作业选项中的“本地子目录 for repo（可选）”选项来指定要使用的目录？
- 如果这一切都失败了，有没有其他方法可以建立一个构建管道，可以与我错过的其他管道共享作业？