检索远程触发的詹金斯工作的ID [英] Retrieve id of remotely triggered jenkins job
问题描述
我正在通过http POST请求从jenkins外部触发参数化的Jenkins:
我已在作业配置中启用了可以从外部触发作业的功能，并且我可以通过向詹金斯发送包含以下内容的请求来真正触发该作业:
POST
http://myJenkins.com/myJob/buildWithParameters?token=MYTOKEN
参数:SCREEN_SIZE:27
触发作业创建将返回成功的201 CREATED http响应.
我的问题是我不知道所创建的构建作业的ID.我想监视工作状态.为了做到这一点，我需要知道的ID.否则，如果我只是接受这份工作的最新版本，那我可能会接受错误的工作.
是否有一种可靠的方法来获取所创建作业的ID?
更新:
其他答案是在我的大约8个月后添加的.我当时不知道响应中的 location 标头.在某些情况下，这确实是一个不错的选择.就是说，根据答案和评论中的警告(尤其是关于 parameterized 构建)，看来该答案在某些情况下仍具有一定的实用性.
原始答案:
不幸的是，他们没有使它变得如此简单.也就是说，例如，返回带有 id 之类信息的 JSON 响应.
但是，我相信一个可靠的解决方法(虽然肯定是不平凡的)是利用您用来触发构建的URL中的 cause 参数，并在此原因中添加唯一文本，您可以稍后对其进行分析，以确定您是从自动化中触发了该文本.
如果要同时执行多个作业(即使是从您的自动化系统开始)，则要进一步使特定作业具有唯一性，还应包括某种类型的 unique ID (它可能只是来自您的序列号原因参数中的 RDBMS 或类似名称.
然后，您可以使用 JSON API 获取有关您要远程触发的作业的信息.再说一次，它是间接的，但是可行的:
命中以下形式的URL:
http://<server>:<port>/job/<jobname>/lastBuild/api/json
您可以添加?pretty=true以在浏览器中漂亮地打印它，以提高人类可读性.
这将为您提供上一版的 JSON .它将在 actions 属性内包含 causes 属性，在其中(另一个名为 shortDescription 的嵌套属性中)，您会找到如果您添加了cause 参数(如果这是您触发的构建之一).
您可以同时解析特殊的静态文本和生成的ID，以查看它们是否匹配.如果这样做，您还可以从 JSON 中获取 Jenkins id (搜索嵌套的 buildNumber ).
如果该构建不是完全由您的自动化触发的，或者是由您触发的，但是ID不匹配，则可以重复执行 N-1个构建的过程，直到找到所需的内容为止正在寻找.
该JSON的格式为:
http://<server>:<port>/job/<jobname>/<buildNumber>/api/json
I am triggering a parameterized Jenkins from from outside of jenkins via a http POST request:
I have enabled in the job configuration that the job can be triggered from outside and i can really trigger it by sending jenkins a request with a content like this:
POST
http://myJenkins.com/myJob/buildWithParameters?token=MYTOKEN
Parameter: SCREEN_SIZE: 27
Triggering the job creation returns a successfull 201 CREATED http response.
My problem is that i dont know the id of the build job that was created. I want to monitor the state of the job. In order to do that i need to know the id. Otherwise, if i just take the latest build of that job, i could take wrong job.
Is there a reliable way to get the id of the created job?
Update:
The other answer was added ~8 months after mine. I was unaware of the location header in the response at the time. That does sound like a good option for some cases. That said, based on the caveats in the answer and the comments (especially around parameterized builds), it appears that this answer still has some utility for some cases.
Original answer:
Unfortunately, they don't make this as straightforward as it could be. i.e. by, say, returning a JSON response with information like an id.
However, I believe a solid, though certainly non-trivial, workaround to that would be to leverage the cause parameter in the URL you use to trigger the build, and within that cause, add unique text that you can later parse to determine that you triggered it from your automation.
To further uniqueify the specific job, in case multiple are running around the same time, even from your automation, also include a unique ID of some type (it could simply be a sequence ID from your RDBMS or similar) inside of the cause parameter.
Then, you can use the JSON API to get information about the job you're remotely triggering. Again, it's somewhat indirect, but doable:
Hit a URL of the form:
http://<server>:<port>/job/<jobname>/lastBuild/api/json
You can add ?pretty=true to pretty-print it within the browser for better human readability.
That will get you the JSON of the last build. It will contain the causes attribute within the actions attribute, and in there (in another nested attribute named shortDescription) you would find the cause parameter you added, if this was one of the builds you triggered.
You could parse out both the special static text, and your generated ID to see if they match. If they do, you can then get the Jenkins id out of the JSON as well (search for buildNumber, which is nested).
If that build is either not triggered by your automation at all, or was, but the ID doesn't match, you can repeat the process for the N - 1 build until you find what you're looking for.
That JSON would be of the form:
http://<server>:<port>/job/<jobname>/<buildNumber>/api/json
这篇关于检索远程触发的詹金斯工作的ID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
