I'm also looking forward to get this feature implemented. I'm developing a ruby API client for Jenkins and many of my users have requested for this feature. Checking the nextBuildNumber and build queue may not give the correct build number. The response from Jenkins for build or buildWithParameters gives the response code of 302. It would be nice to get a JSON or XML response like

{
"buildNumber" : 11
}

this would be great.

https://github.com/arangamani/jenkins_api_client

+1.

There's currently no way to know what happened to your build request without continuously monitoring the queue.

Even if your build number wasn't directly returned, at least have a trigger timestamp or other matching field in the build details so that you can at least query the build list and determine which build corresponded to your request.

+1,

We really need this as well. If someone could contact me we would be happy to sponsor it but can't use paypal.

I'm not sure how easy it will be to add this functionality in the Jenkins API itself. As the build number is determined once the build is moved from the queue to one of the executors, it might be hard to return the build number as soon as the build is triggered. I looked around the code in Jenkins and it doesn't seem to be an easy fix. However I have authored a jenkins_api_client ruby gem which makes use of the new behavior of Jenkins' response to build POST requests.

In recent versions, jenkins returns a location header to the response of the build POST request. This location header contains the location of the queue item for the particular build. This queue item can be continuously queried until it is placed in one of the executors. Once the queue item reaches an executor, it is assigned with a build number.

I have implemented a neat solution here https://github.com/arangamani/jenkins_api_client/issues/88 which will optionally accept an argument on whether to return the build number and return the build number once it is obtained. The only downside is that if there aren't enough idle executors of another build for the same job is running, this call will have to wait until it obtains the build number. Which is why I made this optional so people can decide whether to wait or not.

Any comments on my implementation would be appreciated.

Another idea for a workaround would be to make the build parametrized, e.g. with a parameter "id". On the remote side you could than generate a unique and deterministic build ID that you can later recognize in the builds XML/JSON description.

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.

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.

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?

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.

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