通过解析webhook请求主体/JSONpath来参数化我的回购URL [英] Parameterize my repo url by parsing webhook request body/JSONpath
问题描述
我正在使用多分支管道Jenkins进行设置，并使用Git中的webhook触发了构建.在这里，我选择了Git Branch源作为-Git.
I am working on a multibranch pipeline Jenkins setup and build is triggered using webhook in Git.. Here I have selected Git Branch source as - Git.
当我推送git中的任何更改时，webhook会创建一个带有所有推送事件详细信息的请求正文.如何解析"git_http_url"；值(将包含我的git repo url).然后，可以在jenkins控制台中将此值用作$ {myrepourl}.基本上，我想避免对存储库URL进行硬编码，它应该动态地使用此参数.
When I push any change in git, webhook creates a request body with all push event details. How can I parse "git_http_url" value from this( which will have my git repo url). This value I can then use as ${myrepourl} in jenkins console. Basically I want avoid hardcoding the repo url, it should dynamically take using this parameter.
请指导.
！[webhook请求正文屏幕截图] [2]] [2] [！[附上我的jenkins控制台分支源代码] [1]] [1] [1]:https://i.stack.imgur.com/sdb0l.png [2]:https://i.stack.imgur.com/icPP9.png
![webhook request body screenshots][2]][2] [![attached my jenkins console branch source][1]][1] [1]: https://i.stack.imgur.com/sdb0l.png [2]: https://i.stack.imgur.com/icPP9.png
推荐答案
开始时，这似乎不是一个很好的主意.首先，我将解释原因，概述替代方案，最后提出一个解决方案，如果您坚持要这样做，它可能仍然有效.
This looks like a not-very-good idea to begin with. I will start by explaining why, outlining the alternatives, and in the end suggesting a solution that might still work if you insist on doing this.
配置管道时，需要为其提供Jenkinsfile.可以将其粘贴到配置中("Pipeline脚本")，或者您可以提供它的路径，以便Jenkins可以执行结帐(来自SCM的Pipeline脚本").使用前者时，您只有一个Jenkinsfile，因此不同的分支无法更改它(因此失去了使用多分支的意义).在执行后者时，即使您可以参数化git repo，您仍然需要提供路径(因为它不会在github通知中到达).此外，我可以使用我的存储库触发您的构建，但是您的管道可能仍然无法正确构建我的存储库.因此，您的管道只能建立您的存储库，这时还不清楚为什么您坚持不为特定的管道提供指向您明确知道如何构建的特定存储库的路径.
When you configure your pipeline, you need to provide it with Jenkinsfile. It can be pasted inside the configuration ("Pipeline script"), or you can provide a path to it so Jenkins can perform a checkout ("Pipeline script from SCM"). When doing the former, you have one Jenkinsfile, so different branches can't alter it (and so missing the point of having a multibranch). When doing the latter, even if you can parametrize the git repo, you still need to provide a path (as it won't arrive in github notification). In addition, I can trigger your build with my repo, but chances are your pipeline won't be able to properly build my repo anyway. So your pipeline can only build your repo, at which point it's a bit unclear why you insist on not providing your specific pipeline with a path to your specific repo that it specifically knows how to build.
大多数需要在Github上使用多分支管道的人都使用专门为此目的编写的插件之一，例如Github Multibranch插件或Github组织.这些插件自己完成所有工作:它们注册通知，处理通知并开始构建.他们还会为您更新Github中的构建状态.
Most people who need multibranch pipelines over Github use one of the plugins specifically written for this purpose, e.g. Github Multibranch plugin or Github organization. These plugins do all the job themselves: they sign up for notifications, process them, and start builds. They also update build status in Github for you.
最后，如果您坚持要自己处理Github通知，则可以使用通用Webhook触发器插件，该插件将允许您通过POST-使用令牌访问指定的URL来触发作业.这可能看起来像这样:
Finally, if you insist on processing Github notifications yourself, you can use Generic Webhook Trigger plugin that will allow you to trigger the job by POST-ing to a specified URL with a token. This may look like this:
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的形式提供.
As per the first configuration line, any JSON posted will get flattened and turned into pipeline variables, with a prefix you define (in this case, "DATA_"). E.g. the field git_http_url inside the field project in Github payload will be defined in the pipeline and available to you as DATA_project_git_http_url. As per second configuration line, it will also be available as 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变量.)
In this case, the contributed variable will be DATA_hello and it will have the value of world. (The GITHUB_URL variable, naturally, won't be defined.)
如果要将其转换为真实的Github Webhook处理器，则需要确保Github通知到达<jenkins>/generic-webhook-trigger/invoke?token=my_token.为此，我们使用nginx，但是还有许多其他选择.
If you want to turn this into real Github webhook processor, you need to make sure that Github notifs arrive to <jenkins>/generic-webhook-trigger/invoke?token=my_token. We use nginx for that, but there are many other options.
这篇关于通过解析webhook请求主体/JSONpath来参数化我的回购URL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
