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

api should return the queue url in location header for parameterized builds

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Not A Defect
    • Component/s: core
    • Labels:
    • Environment:
      Jenkins 1.623
    • Similar Issues:

      Description

      When calling POST /job/my-job/build with parameters on a parameterized buil, I don't get the queue item url back in the location header.
      I consider this a bug since it doesn't follow the description of how the API should work according to the comments on JENKINS-12827

      When triggering a non-parameterized build, the headers look like this:

      [date] => Sat, 05 Sep 2015 07:55:45 GMT
      [server] => Jetty(winstone-2.8)
      [x-content-type-options] => nosniff
      [location] => https://jenkins.mydomain/queue/item/15032/
      [content-length] => 0
      [connection] => close
      [content-type] => text/plain; charset=UTF-8
      

      but on a parameterized build the response headers look like this:

      [date] => Sat, 05 Sep 2015 08:07:15 GMT
      [server] => Jetty(winstone-2.8)
      [x-content-type-options] => nosniff
      [location] => https://jenkins.mydomain/job/my-parameterized-job/
      [content-length] => 0
      [connection] => close
      [content-type] => text/plain; charset=UTF-8
      

        Attachments

          Activity

          Hide
          csimons Christopher Simons added a comment - - edited

          Could not reproduce. Here is what I get when I post a request for a parameterized build (my HEAD is 5b4b66d8bcc4c3effae9329236edbfac2bccdd84 in branch 'master'):

          $ curl -i -X POST http://localhost:8080/job/bnt_02/buildWithParameters?profile=foo
          HTTP/1.1 201 Created
          X-Content-Type-Options: nosniff
          Location: http://localhost:8080/queue/item/55/
          Content-Length: 0
          Server: Jetty(winstone-2.8)
          
          $
          
          Show
          csimons Christopher Simons added a comment - - edited Could not reproduce. Here is what I get when I post a request for a parameterized build (my HEAD is 5b4b66d8bcc4c3effae9329236edbfac2bccdd84 in branch 'master'): $ curl -i -X POST http: //localhost:8080/job/bnt_02/buildWithParameters?profile=foo HTTP/1.1 201 Created X-Content-Type-Options: nosniff Location: http: //localhost:8080/queue/item/55/ Content-Length: 0 Server: Jetty(winstone-2.8) $
          Hide
          matthew Matthew Skevington added a comment - - edited

          I am having the same problem. It appears to be happening when you POST to a build containing multipart form data. For example:

          curl -i curl.log -X POST http://localhost:8080/jenkins/job/TestProject1/build?  --user user:password   --form file0=@Documents/buildTest1.xml --form json='{"parameter": [{"name":"build.xml", "file":"file0"},{"name" : "BuildType", "value" : "JSON_BUILD"}]}'
          

          Returns:

          HTTP/1.1 200 OK
          Date: Wed, 04 Nov 2015 11:50:47 GMT
          Server: Apache
          Last-Modified: Wed, 13 Feb 2013 14:51:29 GMT
          ETag: "38c26e-0-4d59c46f63e40"
          Accept-Ranges: bytes
          Content-Length: 0
          Vary: Accept-Encoding
          Content-Type: text/html
          
          HTTP/1.1 100 Continue
          
          HTTP/1.1 201 Created
          Server: Apache-Coyote/1.1
          X-Content-Type-Options: nosniff
          Location: http://localhost:8080/jenkins/job/TestProject1/
          Content-Length: 0
          Date: Wed, 04 Nov 2015 11:51:05 GMT
          
          Show
          matthew Matthew Skevington added a comment - - edited I am having the same problem. It appears to be happening when you POST to a build containing multipart form data. For example: curl -i curl.log -X POST http: //localhost:8080/jenkins/job/TestProject1/build? --user user:password --form file0=@Documents/buildTest1.xml --form json= '{ "parameter" : [{ "name" : "build.xml" , "file" : "file0" },{ "name" : "BuildType" , "value" : "JSON_BUILD" }]}' Returns: HTTP/1.1 200 OK Date: Wed, 04 Nov 2015 11:50:47 GMT Server: Apache Last-Modified: Wed, 13 Feb 2013 14:51:29 GMT ETag: "38c26e-0-4d59c46f63e40" Accept-Ranges: bytes Content-Length: 0 Vary: Accept-Encoding Content-Type: text/html HTTP/1.1 100 Continue HTTP/1.1 201 Created Server: Apache-Coyote/1.1 X-Content-Type-Options: nosniff Location: http: //localhost:8080/jenkins/job/TestProject1/ Content-Length: 0 Date: Wed, 04 Nov 2015 11:51:05 GMT
          Hide
          danielbeck Daniel Beck added a comment -

          Use the API to start builds as described on /job/NAME/api, i.e. /build for parameterless jobs and /buildWithParameters for parameterized jobs, and you won't have a problem.

          Show
          danielbeck Daniel Beck added a comment - Use the API to start builds as described on /job/NAME/api , i.e. /build for parameterless jobs and /buildWithParameters for parameterized jobs, and you won't have a problem.
          Hide
          matthew Matthew Skevington added a comment - - edited

          Using /buildWithParameters does not work if you are adding a file to the request. Jenkins ignores the file unless you use /build, which I believe is already raised as a bug.

          Show
          matthew Matthew Skevington added a comment - - edited Using /buildWithParameters does not work if you are adding a file to the request. Jenkins ignores the file unless you use /build , which I believe is already raised as a bug.
          Hide
          danielbeck Daniel Beck added a comment -

          Possible, however that's a different issue, as you're writing.

          So why is this API behaving differently? You're pretending to be a web browser filling out the form and submitting it. So don't be surprised to get treated as one and redirected to a URL that makes sense for the UI rather than a headless API client.

          Show
          danielbeck Daniel Beck added a comment - Possible, however that's a different issue, as you're writing. So why is this API behaving differently? You're pretending to be a web browser filling out the form and submitting it. So don't be surprised to get treated as one and redirected to a URL that makes sense for the UI rather than a headless API client.
          Hide
          matthew Matthew Skevington added a comment -

          That's fine. But it doesn't really help when you're writing an application that is making use of the Jenkins API. I'm guessing it was designed to be used headlessly.

          Could the API be amended to return the queue url it all circumstances where builds are being requested?

          Show
          matthew Matthew Skevington added a comment - That's fine. But it doesn't really help when you're writing an application that is making use of the Jenkins API. I'm guessing it was designed to be used headlessly. Could the API be amended to return the queue url it all circumstances where builds are being requested?
          Hide
          danielbeck Daniel Beck added a comment -

          That's fine. But it doesn't really help when you're writing an application that is making use of the Jenkins API. I'm guessing it was designed to be used headlessly.

          That's the problem. This is not actually the API. As I wrote before, the API as documented uses /buildWithParameters for parameterized builds. This is pretending to be a web browser.

          Could the API be amended to return the queue url it all circumstances where builds are being requested?

          Not as currently designed, because web browsers would get redirected to a blank 404 error page. Again, you're not actually using the API here, you're pretending to be a web browser.

          Show
          danielbeck Daniel Beck added a comment - That's fine. But it doesn't really help when you're writing an application that is making use of the Jenkins API. I'm guessing it was designed to be used headlessly. That's the problem. This is not actually the API. As I wrote before, the API as documented uses /buildWithParameters for parameterized builds. This is pretending to be a web browser. Could the API be amended to return the queue url it all circumstances where builds are being requested? Not as currently designed, because web browsers would get redirected to a blank 404 error page. Again, you're not actually using the API here, you're pretending to be a web browser.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            ulrik Ulrik Johansson
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: