我正在尝试升级我当前的回归基础设施以使用管道插件，我意识到有两种方法：scripted pipeline和declarative pipeline. 通过多篇文章，我意识到它declarative pipeline更具未来性和更强大，因此我倾向于使用它。但似乎有以下限制，我不想在我的设置中拥有：
jenkinsfile需要在存储库中。我不想将我的保留jenkinsfile在代码存储库中。
由于jenkinsfile需要在单片机中。这是否意味着在将文件签入存储库之前，我无法测试文件中的任何修改。
上面的任何细节都将非常有帮助。
声明性管道被编译成脚本化的，所以这些肯定不会消失。但是声明性的更容易处理，所以对你来说一切都很好。
您不必检查JenkinsfileVCS。您还可以设置Pipeline类型的作业并在那里定义它。但这具有通常的缺点，例如没有历史记录等。
当使用多分支管道时，即每个分支都包含一个Jenkinsfile生成自己的作业，您只需将更改的管道推送到新分支并执行它。完成后，您将其合并。
这种方法肯定会增加一点反馈周期，但它只是应用与编写软件时相同的原则。对于实验，只需设置一个Pipeline类型的作业并进行操作。之后，将其提交到一个分支，对其进行测试、审查、合并。
您可以为此使用Pipeline Multibranch Defaults 插件。它允许您在 Web UI（使用 Config File Provider 插件）本身中定义 Jenkinsfile，然后从 Multibranch Pipeline 引用该文件。