构建流程与构建管道

Question

我试图使用Build Flow插件分割一些Jenkins工作，这样我们就有三个＆＃34;起点和＃34;而不是三个整体工作。然后使用DSL触发下游作业。我在Build Pipeline插件上选择了Build Flow，因为在不同的管道之间共享作业似乎要困难得多（即，用一个编译作业共享多个启动作业的工作区）。

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

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

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

Project-PROD只会被手动触发，并且会完成整个单元和集成测试套件，编译和缩小前端代码（Less，JS和CSS），并将构建的代码推送到特殊的＆ ＃34;发布分支＆＃34;在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”＆＃39;工作。但是它不是在同一个目录中工作，而是获得一个名为＆＃34; / sharedspace / shared_one @ 2＆＃34;的目录，并在那里运行构建设置任务。然后，当它进行第三步（单元测试）时，它失败了，因为它现在有第三个目录（/ sharedspace / shared_one @ 3），但该目录没有设置运行，所以缺少所需的节点和编写器模块。奇怪的是，看起来共享工作区插件正在将第一个共享工作区复制到另一个目录并递增计数器（目录名的@N部分）并将其提供给其他工作。< / p>

所以，提问时间：

1. 有没有办法修复Shared Workspace插件，以便它实际上只为每个作业使用一个目录？
2. 如果没有，是否可以让Clone Workspace插件接受参数，这样我可以指定要使用的归档工作区而不是使用下拉列表？
3. 另一种可能性：将使用共享工作区插件，但使用＆＃34; Local子目录进行repo（可选）＆＃34;高级git作业选项中的选项指定要使用的目录？
4. 没有做到这一点，还有其他方法可以设置一个可以与我错过的其他管道共享作业的构建管道吗？

Answer 1

根据我的经验，即使你做让这个工作，这可能不是一个可扩展的长期方式。我们发现共享工作区插件对于长/复杂构建来说完全不是一个坏主意（与你的类似的原因 - 但是：跨越几十个奴隶的扩展会突然变得困难）。可以说，这个想法略微违背了现代可扩展CI的精神。

我会更多地委托你的构建工具，无论是Maven / Gradle，Ant，甚至是Grunt，等等。如果你想保持这些构建真正模块化，但不能在每一步重建（我们认为完全独立值得浪费每个构建几分钟）然后可能会考虑在关键阶段创建有用的人工制品 - 在你的情况下，缩小资产TAR，库JAR，或者webjars，或者其他什么，并将他们部署到（Maven？）仓库。

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

另一种选择（具有相似性）是构建一个或多个资产，但只有提升后才能运行，这可以在构建流程协调的单独构建中完成，使用Promoted Builds plugin等。