Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-13546

buildWithParameters: return a JSON string when client request it through content-type header

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Jenkins 1.460 on Debian Squeeze

      Right now, every call on the buildWithParameters URL will always redirect to the job page on success. If this API is queried through an Ajax call, it should return a JSON output of the current job instead. This can easily be detected based on the Content-Type http header sent by the client.

      This is useful for example if one wants to trigger a parametrized build from jQuery, and parse the result. Right now, jQuery will always get back the HTML page of the job, which makes it hard to do any error handling.

          [JENKINS-13546] buildWithParameters: return a JSON string when client request it through content-type header

          Sune Keller added a comment -

          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 Keller added a comment - 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 Roussel added a comment - @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 ...

          Sune Keller added a comment -

          @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 Keller added a comment - @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.

          Bertrand Roussel added a comment - - edited

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

          Bertrand Roussel added a comment - - edited @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.

          François Granade added a comment - - edited

          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 ?

          François Granade added a comment - - edited 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.

          SCM/JIRA link daemon added a comment - 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.

          dogfood added a comment -

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

          Result = SUCCESS
          kohsuke : 680dd4a21a575cebe37648b215b8f714848f6a15
          Files :

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

          dogfood added a comment - 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

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

          Andrew Kujtan added a comment -

          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.

          Andrew Kujtan added a comment - 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.

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

            corfr Bertrand Roussel
            rborer Reynald Borer
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: