Daniel Beck added a comment - 2014-05-21 16:45 Build numbers don't get assigned to queued builds, and for good reason: Between QueueSorter, QueueTaskDispatcher, and plugins like Set Next Build Number, this is impossible to determine before actually starting the build. Then there's the issue of canceling queue items – they don't (and shouldn't) use up build numbers, which this change would necessitate (or result in wrong results, as a specific build number could be queued and canceled again multiple times). However, there's an easy API solution that considers that issue when triggering builds. Trigger the build and check the headers: $ curl -i --netrc http: //jenkins/job/triggerable-remotely/build?token=ABC HTTP/1.1 201 Created Date: Wed, 21 May 2014 16:37:58 GMT Server: Jetty(8.y.z-SNAPSHOT) Location: http: //jenkins/queue/item/25/ Content-Length: 0 Connection: close Content-Type: text/plain; charset=UTF-8 Get the Location value, and check its API at e.g. /queue/item/25/api/xml (formatted for readability): <waitingItem> <action> <cause> <shortDescription>Started by remote host xxx.xxx.xxx.xxx</shortDescription> </cause> </action> <blocked> false </blocked> <buildable> false </buildable> <id>25</id> <inQueueSince>1400690278070</inQueueSince> <params/> <stuck> false </stuck> <task> <name>triggerable-remotely</name> <url>http: //jenkins/job/triggerable-remotely/</url> <color>blue</color> </task> <url>queue/item/25/</url> <why>In the quiet period. Expires in 38 sec</why> <timestamp>1400690328070</timestamp> </waitingItem> This contains all the information you could possibly want here. And once the build starts and a build number has finally been assigned, you get the build number and build URL: <leftItem> <action> <cause> <shortDescription>Started by remote host xxx.xxx.xxx.xxx</shortDescription> </cause> </action> <blocked> false </blocked> <buildable> false </buildable> <id>25</id> <inQueueSince>1400690278070</inQueueSince> <params/> <stuck> false </stuck> <task> <name>triggerable-remotely</name> <url>http: //jenkins/job/triggerable-remotely/</url> <color>blue_anime</color> </task> <url>queue/item/25/</url> <cancelled> false </cancelled> <executable> <number>6</number> <url>http: //jenkins/job/triggerable-remotely/6/</url> </executable> </leftItem> As this feature is at least next to impossible to implement in a backwards compatible way, and has an easy, complete solution already, I'm resolving this as Won't Fix.

Daniel Beck added a comment - 2014-05-31 19:38 JENKINS-16827 : Jenkins tries to guess the build number before it can be determined, gets it wrong, and it's (correctly) reported as a bug.

Patrick Waters added a comment - 2014-12-25 22:27 I'd like to reopen this issue, and ask for feature request. Currently when you start a job using the api, you do get back the queue location url. This is great. But the problem is that requires me to keep checking until a build number get's assigned. I don't know what the time to live is on the queue id, but it seem short lived. So if I happen to miss it, the connection between the queue id and the job is gone forever. What I think would be a good idea is to associated the queue id with the build id. So basically, even if the item isn't in the queue anymore, I can still lookup the job via the queue id. Thoughts?

Daniel Beck added a comment - 2014-12-25 22:34 That's a different request (queue items may be too short lived, and fixing that alone may be sufficient for you), so please file a new request. You can link it to this one via More Actions » Link to declare it related.

Russell Weber added a comment - 2015-10-19 20:51 - edited I am vexed by the same problem. However, rather than re-open this issue, I opened the following bug: https://issues.jenkins-ci.org/browse/JENKINS-31039