这看起来不是一个很好的主意。我将首先解释原因,概述替代方案,最后提出一个如果你坚持这样做可能仍然有效的解决方案。
配置管道时,需要为它提供 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 有效负载中的字段git_http_url
内的字段project
将在管道中定义并作为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
它,但还有许多其他选择。