> On 11.05.2016, at 14:41, S C <[email protected]> wrote: > > However: the page only talks about POSTing to URL, says nothing about sending > URL parameters with PUT (or GET), and also recommends - guess what - the > "hackish" way of sending the params as form data! It even says that using the > remote trigger plugin is "deprecated" so... if I'm not mistaking it goes > exactly against all the recommendations above.
Yes, the parameters. Not the JSON object. Due to the problems with requiring read access to use the token you experienced, I generally recommend against using the trigger token. We really should move this into a plugin and let it fade away… > Now if only GETting from that trigger address would return me "building job > xyz..." if still building and the (latest if done) build location - instead > of triggering a new build... Now that GET will change state and in the event > of a automatic retry - not so unheard-of - would try to change state many > times, then it would be a perfect world! How would that work with parallel builds, etc.? Admittedly, not the cleanest of APIs, but you should be able to achieve your goals anyway. The API, if used correctly, will return the queue item URL whose API you can query for status. > It's also worth noticing that I cannot cancel in GUI a build job queued via > remote trigger. I guess because it was not queued by my GUI user - it makes > sense but still not very convenient (I'm in GUI an admin user so I had > expectations...). Very unusual. This is not the case with Jenkins out of the box, so it's possible a plugin interferes. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5318B11F-0E2A-4051-863B-DC0013A6895D%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
