我们在存储库的子文件夹中有一些代码，这些代码用作新存储库的源模板，这些存储库本身具有完整的CI / CD管道，可以部署到服务器并处理工作。
通过对该子文件夹运行源模板存储库的Jenkins构建/部署管道（如在Jenkinsfile中捕获的）来进行一些附加的自动化测试，而无需首先从中创建新的存储库，这将非常有价值。唯一要注意的是，有些模板占位符必须先注入值，然后才能进行构建/部署。
理想情况下，最佳方案是使用模板文件夹中确切的Jenkinsfile管道脚本。但是，天真地创建指向该Jenkinsfile的Jenkins管道作业似乎不起作用，因为：
我花了一些时间试图弄清楚如何实现这一目标，但到目前为止还没有成功。这是我尝试过或研究过/想到的：
将模板Jenkinsfile分为两部分，the pipeline {}部分和steps {}部分，然后使用自定义的Jenkinsfile创建一个新的管道作业，尝试加载步骤文件。这是行不通的，因为您不能从一个步骤中调用一个步骤，也无法运行任何脚本，而该脚本会在一个步骤之外运行另一个常规文件（我已经弄清楚了）。这不是完美的，因为模板化的应用程序会将其Jenkinsfile分为两部分，并且测试场景将不会使用 exact 相同的管道脚本，但这将很有价值。 / p>
创建一个自由样式项目，该项目执行SCM检出，在本地进行所有需要的修改（快速模拟整个模板化过程，而无需创建新的存储库），对模板子文件夹进行更改（并可能进行更改）修改工作目录或根据需要移动文件/将其删除，以使模板化的应用程序位于根目录中），然后启动应该在此处运行的现有Jenkinsfile管道脚本。我尝试过此方法，但无法弄清楚如何直接从自由式项目中启动管道作业。
制作一个自由式项目，执行与上述相同的过程，然后保存工件，然后创建将这些工件用作其构建源的另一个管道作业。但是我什至不确定这是否可行，我已经花了太多的研究时间。
执行快速模板化过程，并为此在每个存储库中的某个存储库中创建一个新分支（也许以内部版本号命名），然后执行一个使用该分支作为其源的下游管道作业。这可能行得通，但是带来了更多的复杂性，并且对仓库的外部依赖性使仓库中的分支需要清理，从而需要另一项工作，而这项工作本身可能并不总是能够成功运行。不必这样做会非常好。
将模板的Jenkinsfile复制到父存储库的另一个位置，并自动添加所需的步骤以对其进行模板化并使用子文件夹。但是，这远非理想，因为那时我们正在使用代码以自定义方式编写代码（漏洞/破损的巨大来源），而且，几乎相同的代码必须放在两个位置，并且两者之间可能会出现差异。两个Jenkins文件在大多数地方应该是相同的。
在某些开发人员端的预处理构建过程中，获取模板的Jenkinsfile，注入子文件夹并模板化更改，然后将其副本保存在其他位置，以进行任何其他更改。不理想。不应提交生成的文件，这给开发人员造成了负担，并且可能难以执行-似乎很脆弱，而且不是防止两个Jenkinsfiles之间出现差异蔓延的有效策略。关于代码编写代码的问题仍然相同。
向父仓库添加自动提交，以更新Jenkinsfile副本，而不是让开发人员执行。虽然不经常更改Jenkinsfile，但这种额外的提交很丑陋，而且存在许多与以前的想法相同的问题。
就是这样-现在我没主意了。
关于如何在不增加额外复杂性或工作的情况下实现我所寻找的任何建议？
背景：目前，我们还没有针对模板的某些部分进行任何自动化测试，因为对所有部分进行全面测试不仅需要构建或运行单元测试，还需要将（模板化的）应用程序实际部署到服务器来测试部署代码本身，并针对成功部署的结果运行端到端测试。理想情况下，长期的解决方案实际上是运行新仓库的过程，然后从那里进行测试，但这将花费大量时间，并且工作需要完全自动化的创建/模板化，测试和拆除。另外，有必要让模板源存储库等待所有测试完成，然后才能将其自己的测试过程标记为成功。因此，通过从子文件夹中按原样部署应用程序（只需完成较小的模板化）即可获得大部分价值的快速解决方案将非常出色。长期来看，我们将远离Jenkins，但现在需要进行此测试！