Retrieve id of remotely triggered jenkins job

Question

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?

Answer 1

Since Jenkins 1.519, enqueuing a build responds with a URL in the Location, pointing you to an item in the build queue:

$ nc localhost 8666 POST /jenkins/job/morgRemote/buildWithParameters?jenkins_status=1&jenkins_sleep=20&token=morgRemote HTTP/1.1 Host: localhost:8666  HTTP/1.1 201 Created Location: http://localhost:8666/jenkins/queue/item/39/ Content-Length: 0 Server: Jetty(winstone-2.8) 

Now if you add api/json (or api/xml and so on) to the end of it (so in this example it would be http://localhost:8666/jenkins/queue/item/39/api/json) then you will get a document that will contain build id for the given job. For json the retrieved object has executable attribute, which in turn has number and url attributes. number is the build id for the given job (35 here) and url is the jenkins build page url.

{   "actions" : [     {       "parameters" : [         {           "name" : "jenkins_status",           "value" : "1"         },         {           "name" : "jenkins_sleep",           "value" : "20"         }       ]     },     {       "causes" : [         {           "shortDescription" : "Started by remote host 127.0.0.1",           "addr" : "127.0.0.1",           "note" : null         }       ]     }   ],   "blocked" : false,   "buildable" : false,   "id" : 39,   "inQueueSince" : 1423993879845,   "params" : "\njenkins_status=1\njenkins_sleep=20",   "stuck" : false,   "task" : {     "name" : "morgRemote",     "url" : "http://localhost:8666/jenkins/job/morgRemote/",     "color" : "red"   },   "url" : "queue/item/39/",   "why" : null,   "cancelled" : false,   "executable" : {     "number" : 35,     "url" : "http://localhost:8666/jenkins/job/morgRemote/35/"   } } 

be aware of 2 things:

• inactive items in the build queue are garbage collected after few minutes, so you should retrieve build id ASAP
• by default it takes few seconds between item is added to the queue until it gets build id. During this time executable and canceled attributes will be missing and why will be not null. You can change this behavior in "Advanced Project Options" of your job config by modifying "Quiet period" setting or in the jenkins global configuration.

:

  ...   "url" : "queue/item/39/",   "why" : "In the quiet period. Expires in 2.4 sec",   "timestamp" : 1423993879845 } 

Answer 2

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