创建“多分支”管线时，您有几个行为选项-这些选项将确定如何触发管线，或更精确地说，何时触发管线（假设相关原点在定义的路径中有Jenkinsfile）。
此外，每个行为都有一个特定的策略，可以选择，并会影响结果。
默认行为是 * 发现分支 、 发现来自分支的拉取请求 * 和 * 发现来自源节点的拉取请求 *。我将忽略分支选项，因为它与开源Git工作流更相关。

*发现来自源的拉入请求-发现源资料档案库与目标资料档案库相同的拉入请求。这意味着对于打开的每个拉入请求，都将创建一个具有拉入请求ID的新管道，并且在创建时以及将来与拉入请求相关的源代码发生任何更改时都会触发该管道。关闭拉入请求时，管道将被删除。

关于策略，您可以选择构建拉取请求中的当前代码（不合并），将其与目标分支合并后的代码，或者两个选项都构建。

**When to use？**当您希望在合并代码之前运行验证流（管道）时。
*发现分支-发现已配置资料档案库中的所有分支，并为每个分支创建专用管道。只要更改该分支的源代码（推送新代码），就会触发管道。

通常，此选项使用 Exclude branches that also files as PRS 策略设置-如果变更已作为拉入请求的一部分进行测试，则可避免重复运行。

**什么时候使用？**当你想运行一个验证流程，比如单元测试或编译，对你所有分支上的每一个代码更改进行验证，并获得快速反馈。

有更多的行为可用，如 * 发现标签 * 和通过定义的正则表达式运行的能力，您也可以使用 * 例外 * 和 * 默认值 * 部分创建各种组合，如：运行在所有拉取请求和以RELESE开头的分支上。因此，它非常灵活，可以轻松地适应您的需要。此外，Jenkins声明性管道附带内置条件，允许您检测您是在分支流还是在拉取请求流中，并拥有一个用于所有不同流的Jenkinsfile。
回到您的问题，如果您希望您的管道只为拉取请求运行，而不为任何分支运行，请删除所有行为，只保留Discover pull requests from origin行为。
还可以考虑使用策略 * 将拉取请求与当前目标分支修订合并 *，以确保实际测试拉取请求合并的结果。