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

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

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Jenkins 1.460 on Debian Squeeze
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            rborer Reynald Borer created issue -
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            scm_issue_link SCM/JIRA link daemon made changes -
            Field Original Value New Value
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Resolved [ 5 ]
            Hide
            dogfood dogfood added a comment -

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

            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
            Show
            dogfood dogfood added a comment - 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
            Hide
            absukl_almbrand 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.

            Show
            absukl_almbrand 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.
            absukl_almbrand Sune Keller made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            corfr Bertrand Roussel made changes -
            Status Reopened [ 4 ] In Progress [ 3 ]
            corfr Bertrand Roussel made changes -
            Assignee Bertrand Roussel [ corfr ]
            Hide
            corfr 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 ...

            Show
            corfr 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 ...
            Hide
            absukl_almbrand 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.

            Show
            absukl_almbrand 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.
            Hide
            corfr 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.

            Show
            corfr 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.
            Hide
            farialima 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 ?

            Show
            farialima 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 ?
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            scm_issue_link SCM/JIRA link daemon made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            Hide
            dogfood 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
            Show
            dogfood 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
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            andrewk 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.

            Show
            andrewk 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.
            andrewk Andrew Kujtan made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            danielbeck Daniel Beck made changes -
            Link This issue is related to JENKINS-22865 [ JENKINS-22865 ]
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            danielbeck Daniel Beck made changes -
            Resolution Fixed [ 1 ]
            Status Reopened [ 4 ] Resolved [ 5 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 144012 ] JNJira + In-Review [ 190858 ]

              People

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

                Dates

                Created:
                Updated:
                Resolved: