@Sune: I see what you mean, I've made few experiments and now I have a better idea of what the "queueItem" actually returns.
As for the randomness, as soon as the queued item is being processed, it pops out of the queue, so (maybe) if the process as started before the project gets serialized to be served as a JSON Object, then the queue Item is null.
It might not be the exact scenario, but in any case the "queueItem" is indeed not reliable, and the queued item object (WaitingItem) returned when scheduling does not offer much support either (enclosed infos, such as timestamp, etc ... are not kept when creating a build object).
I might be wrong, but it seems it would be hard to return informations such as "Ok, I scheduled this task, number is 33 and you will find the build at http://my-jenkins/job/MyJob/33/".
This is what I wanted at first but it seems it would be difficult due to the process, which appears to be:
- Request Processing: Let's queue that WaitingItem # This is where the request result is built
- Job Processing: Let's take that WaitingItem and process it # This is where a "Build" is created
Maybe it would be ok to attribute a GUID to the queued item, and keep that GUID in the build item.
At some point it could provide an 'Jenkins instance'-wide id for a build item, which seems more reliable than a Job Name + Build Number relation.
I will try to provide a proof of concept by the end of the day.
Code changed in jenkins
User: Reynald Borer
Path:
changelog.html
core/src/main/java/hudson/model/ParametersDefinitionProperty.java
http://jenkins-ci.org/commit/jenkins/1409fdff1955581b91904d73781054a63f1d6f85
Log:
[FIXED JENKINS-13546]: return a JSON string when client request it through content-type header
When a client uses the buildWithParameters API and request a json output, return the job definition as a json string instead of doing a redirect on the job page.