Actually I think my second question might have been a bit premature - I think I have been misreading things (it's late here in the UK) - from what I can tell every kind of parameter really does go via /buildWithParameters. :-)
On Sun, Aug 3, 2014 at 10:52 PM, Salim Fadhley <[email protected]> wrote: > A few more REST questions: > > According to the documentation parameters for builds need to get submitted > as form-fields, simple enough but I also notice that the Build with > Parameters form submits an additional hidden JSON encoded form field. Is > that actually used for anything? (presumably not since the docs make no > mention) > > Also I'm having some difficulty in the case of submitting files and > non-file fields. > > I've noticed that when one of the parameters is a file, the form seems to > submit to /build rather than /buildWithParameters. As an experiment I set > up a script to try to trigger a parameterized build with both files and > non-file parameters. If I submitted this to /buildWithParameters results in > everything except the file parameters being received. If I submitted to > /build then only the file parameters are received. So does Jenkins > distinguish between parametrized jobs which do / don't have file > parameters? > > Hopefully this is just a case of something a little screwy in my own code! > > Sal > > > On Sun, Aug 3, 2014 at 8:57 PM, Salim Fadhley <[email protected]> > wrote: > >> Thanks for this! It was a case of wrong URL on the build trigger. You >> guys are awesome. >> >> As a result of your assistance Python Jenkins users will now be able to >> start builds and know exactly what happened as a consequence. >> >> Sal >> >> >> On Sun, Aug 3, 2014 at 10:33 AM, Daniel Beck <[email protected]> wrote: >> >>> Cannot reproduce the problem. >>> >>> Two options I could think of: >>> - You're using the wrong URL. Parameterized jobs need you to use >>> /buildWithParameters, see second sentence you quoted. >>> - You're using a plugin that implements the QueueDecisionHandler >>> extension point and vetoes scheduling of the task, in which case there is >>> no queue item. Run `Queue.QueueDecisionHandler.all()` in script console to >>> check. This returns an empty list for me. >>> >>> On 03.08.2014, at 02:10, Salim Fadhley <[email protected]> wrote: >>> >>> > Thanks Jesse, >>> > >>> > According to the docs the /build method should always redirect over to >>> a /queue/item URL: >>> > >>> > "To programmatically schedule a new build, post to this URL. If the >>> build has parameters, post to this URL and provide the parameters as form >>> data. Either way, the successful queueing will result in 201 status code >>> with Location HTTP header pointing the URL of the item in the queue. By >>> polling the api/xml sub-URL of the queue item, you can track the status of >>> the queued task. Generally, the task will go through some state >>> transitions, then eventually it becomes either cancelled (look for the >>> "cancelled" boolean property), or gets executed (look for the "executable" >>> property that typically points to the AbstractBuild object.)" >>> > >>> > However I've noticed that when the build has parameters it can >>> redirect to Job's URL (not a queue), e.g something that looks like this: >>> > >>> > http://localhost:8080/job/my_job >>> > >>> > and not like this: >>> > >>> > http://localhost:8080/queue/item/1234 >>> > >>> > I'm using 1.574 >>> > >>> > Sal >>> > >>> > On 2 Aug 2014 01:48, "Jesse Glick" <[email protected]> wrote: >>> > On Wed, Jul 30, 2014 at 5:15 PM, Salim Fadhley <[email protected]> >>> wrote: >>> > > What'd really want is a change to the /build and /buildWithParmeters >>> so that >>> > > instead of just returning an HTTP status code, I'd like to see some >>> more >>> > > detailed status. It ought to be able to identify the queue item or >>> ongoing >>> > > build that was generated as a result of attempting to start the job. >>> > >>> > It already returns the queue item information, which allows you to >>> > track the item through to an actual build (if it is ever scheduled). >>> > The "Perform a build" section of the documentation page found from the >>> > "REST API" link on a job's index page gives details. >>> > >>> > -- >>> > You received this message because you are subscribed to a topic in the >>> Google Groups "Jenkins Developers" group. >>> > To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/jenkinsci-dev/_vYBkV3hVtU/unsubscribe. >>> > To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> > For more options, visit https://groups.google.com/d/optout. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Jenkins Developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/jenkinsci-dev/_vYBkV3hVtU/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
