github - 构建流程与构建管道

Question

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

之前，我设置了三个作业: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)，并将构建的代码推送到一个特殊的“发布分支”在 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”的目录，并在那里运行build设置任务。然后当它进行第三步(单元测试)时，它失败了，因为现在它有第三个目录(/​​sharedspace/shared_one@3 )，但该目录没有运行安装程序，所以需要节点和 Composer 缺少模块。奇怪的是，看起来 Shared Workspace 插件正在将第一个共享工作区复制到另一个目录并增加一个计数器(目录名称的 @N 部分)并将其提供给其他工作。

那么，提问时间:

有没有办法修复共享工作区插件，以便它实际上只为每个作业使用一个目录？

如果没有，是否可以让克隆工作区插件接受参数，以便我可以指定要使用的存档工作区而不是使用下拉列表？

另一种可能性:是否会使用共享工作区插件，但使用高级 git 作业选项中的“本地子目录用于 repo(可选)”选项来指定要使用的目录？

如果所有这些都失败了，是否有其他方法可以设置构建管道，该管道可以与我错过的其他管道共享作业？

Answer 1

根据我的经验，即使您确实使这项工作有效，从长远来看，这可能不是一种可扩展的方式。我们发现共享工作区插件对于长时间/复杂的构建完全是一个坏主意(与您的原因类似 - 但还有:跨数十个奴隶进行扩展突然变得困难)。可以说，这个想法有点违背现代可扩展 CI 的精神。

相反，我将更多地委托(delegate)给您的构建工具，无论是 Maven/Gradle、Ant，还是 Grunt，等等。如果你想让这些构建真正模块化，但又不能在每一步都重建(我们认为完全独立值得每个构建浪费几分钟)那么也许可以考虑在关键阶段创建有用的人工制品 - 在你的情况下，缩小 Assets TAR、库 JAR 或 webjars ，或其他什么，并将它们部署到(Maven？)存储库。

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

另一种选择(具有相似性)是构建一个或多个 Assets ，但只有在运行越来越多的测试之后才能提升它们，这可以在由您的构建流程协调的单独构建中完成，使用 Promoted Builds plugin等等。