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.

Integrated in jenkins_main_trunk #1689
[FIXED JENKINS-13546]: return a JSON string when client request it through content-type header (Revision 1409fdff1955581b91904d73781054a63f1d6f85)

Result = UNSTABLE
Kohsuke Kawaguchi : 1409fdff1955581b91904d73781054a63f1d6f85
Files :

• core/src/main/java/hudson/model/ParametersDefinitionProperty.java
• changelog.html

Integrated in jenkins_ui-changes_branch #26
[FIXED JENKINS-13546]: return a JSON string when client request it through content-type header (Revision 1409fdff1955581b91904d73781054a63f1d6f85)

Result = SUCCESS
Kohsuke Kawaguchi : 1409fdff1955581b91904d73781054a63f1d6f85
Files :

• core/src/main/java/hudson/model/ParametersDefinitionProperty.java
• changelog.html

I'm having trouble with the JSON results when scheduling several concurrent builds from a Groovy Postbuild script in another job.

The returned JSON content does not indicate anything about the scheduled build, the queueItem object is sometimes null, and the nextBuildNumber is not reliable when scheduling multiple builds at the same time.

The JSON returned would be infinitely more useful if it contained information about the scheduled build.

@Sune: It seems the "queueItem" should contain informations about the scheduled item, could you please provide more details about when this is null ? Is that random (for a same type of build, even if the build has been scheduled, sometimes the queueItem is null, sometimes it isn't), or is that more for some type of builds, etc ...

@Bertrand: It is random, but notably so in the context of a job allowing concurrent builds, and when multiple builds are scheduled within a short amount of time. In my case I have a job A which, when built, uses the Remote API to start builds of job B. The build of job A, let's name it A-1, wants to print links in its console output to the B builds B-1, B-..., B-N it has scheduled.

@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.

I'm able to consistently reproduce a case where the JSON returned by the 'buildWithParameters' API is incorrect. Here's how I get it, from a clean Jenkins install:

• I created a very simple job "myjob" with one parameter "param". Made it execute a shell that simply contains "sleep 3600" (one hour)
• I set the # of executors to 1, and I start one build (with parameter value "value0") to ensure that subsequent builds will be queued, for example running from the command line:
  curl -H 'Accept: application/json' -d 'param=value0' 'http://localhost:8080/job/myjob/buildWithParameters'
• Then I start two builds, one immediately after the other. From the command line, I simply run:
  curl -H 'Accept: application/json' -d 'param=value1' 'http://localhost:8080/job/myjob/buildWithParameters'; echo; curl -H 'Accept: application/json' -d 'param=value2' 'http://localhost:8080/job/myjob/buildWithParameters'
• The output for both commands are the same: they both return the queue item of the first of the two (the one with param=value1). So it's not possible to use the data returned as a way to look up in the queues, to later get the build id, etc...

Does it help ?

Also, should I open a different Jira issue ?

Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
core/src/main/java/hudson/model/ParametersDefinitionProperty.java
http://jenkins-ci.org/commit/jenkins/680dd4a21a575cebe37648b215b8f714848f6a15
Log:
[FIXED JENKINS-13546]

Bringing this to the parity with ParameterizedJobMixIn.doBuild()

Instead of returning JSON, it returns "201 Created" and responds with the location of the queue item, through which the caller can track how it passes through the queue and eventually gets built/cancelled.

The approach in pull request #750 that relies on
AbstractProject.getQueueItem() is inherently unreliable, because
item can be immediately built before the JSON is rendered, or it might
corresponds to other queued items if the build supports concurrent
builds, etc.

Integrated in jenkins_main_trunk #3328
[FIXED JENKINS-13546] (Revision 680dd4a21a575cebe37648b215b8f714848f6a15)

Result = SUCCESS
kohsuke : 680dd4a21a575cebe37648b215b8f714848f6a15
Files :

• core/src/main/java/hudson/model/ParametersDefinitionProperty.java

Code changed in jenkins
User: Daniel Beck
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/14b6e10243522cd7d3db58d55a2363ef51fe3440
Log:
Noted #648, #737, #733, JENKINS-13546

I'm a little confused as to how this is supposed to work, it now returns,

http://jenkins/queue/item/####/

By the time I get the URL it always 404s.
How is one supposed to "track how it passes through the queue and eventually gets built/cancelled" from the provided URL?

Also, the 200 -> 201 change should be documented in the change logs.

You need to add /api/xml to the queue item URL. That it 404's is probably an oversight as it's never supposed to be accessed interactively?

Still, this can probably be considered Fixed or Won't Fix, depending on how you look at it.