这看起来不是一个很好的主意。我将首先解释原因，概述替代方案，最后提出一个如果您坚持这样做可能仍然有效的解决方案。
当您配置管道时，您需要为它提供 Jenkinsfile。它可以粘贴在配置中（“管道脚本”），或者您可以提供一个路径，以便 Jenkins 可以执行结帐（“来自 SCM 的管道脚本”）。执行前者时，您有一个 Jenkinsfile，因此不同的分支无法更改它（因此错过了拥有多分支的意义）。在执行后者时，即使您可以参数化 git repo，您仍然需要提供路径（因为它不会到达 github 通知中）。此外，我可以使用我的 repo 触发您的构建，但您的管道很可能无论如何都无法正确构建我的 repo。因此，您的管道只能构建您的存储库，此时有点不清楚为什么您坚持不为您的特定管道提供它专门知道如何构建的特定存储库的路径。
大多数需要通过 Github 进行多分支管道的人使用专门为此目的编写的插件之一，例如Github Multibranch 插件或 Github 组织。这些插件自己完成所有工作：它们注册通知、处理它们并开始构建。他们还会为您更新 Github 中的构建状态。
最后，如果你坚持自己处理 Github 通知，你可以使用 Generic Webhook Trigger 插件，它允许你通过POST-ing 到带有令牌的指定 URL 来触发作业。这可能如下所示：
pipeline {
agent { node { label 'master'} }
triggers {
GenericTrigger(causeString: 'Generic Cause',
genericVariables: [
[key: 'DATA', value: '$'], //JSONPath expression meaning "everything"
[key: 'GITHUB_URL', value: '$.project.git_http_url']
],
printContributedVariables: false, // change to 'true' to see all the available variables in the console
printPostContent: false, // change to 'true' to see the dump of the POST data
silentResponse: false,
token: 'my_token')
}
根据第一个配置行，发布的任何 JSON 都将被展平并转换为管道变量，并带有您定义的前缀（在本例中为“DATA_”）。例如。 Github 有效负载中 project 字段内的字段 git_http_url 将在管道中定义并作为 DATA_project_git_http_url 提供给您。根据第二个配置行，它也将作为GITHUB_URL 提供。
您可以使用例如测试您的管道
curl -XPOST -H "Content-Type: application/json" 'http://<jenkins>/generic-webhook-trigger/invoke?token=my_token' --data '{"hello": "world"}'
在这种情况下，贡献变量将为DATA_hello，其值为world。 （GITHUB_URL 变量自然不会被定义。）
如果你想把它变成真正的 Github webhook 处理器，你需要确保 Github 通知到达<jenkins>/generic-webhook-trigger/invoke?token=my_token。我们为此使用nginx，但还有许多其他选项。