On Thu, Nov 29, 2012 at 11:14 AM, John Sirois <[email protected]> wrote:
> It would be great if the BUILDS could be user-keyed to prevent this. Then > the client could send say a guid as the build id, and retrieve the build > result later by either build number _or_ id. To be clear - I'm suggesting this be a 1st level concept in jenkins api and core code. > > > On Thu, Nov 29, 2012 at 11:11 AM, Jesse Glick <[email protected]>wrote: > >> On Wed, Nov 28, 2012 at 7:00 AM, Shen,Hui <[email protected]> wrote: >> > I try to programmatically schedule a new build by posting a message to >> > >> > http://HOSTNAME:PORT/jenkins/job/JOBNAME/build >> > >> > This is worked, a new build was fired, but how can I get the build >> number it >> > just fired. >> >> In general I think you cannot do this. The job may be sitting in the >> queue for a while waiting for an executor, so this API cannot return a >> synchronous result that includes a build number which might not be >> determined for another hour! >> >> That said, it would be worth considering the ability to pass an >> arbitrary cookie (such as a random UUID) to the /build API which would >> be recorded in the build cause. Then your remote client could poll the >> build list until it finds one with a matching cause. The trouble is >> that you could be waiting forever if the queue item is canceled before >> any build is started. So the cookie might need to be included in the >> remote API information about the build queue, too, maybe with a list >> of (recently?) canceled items with associated cookies. Not a simple >> API design problem. >> > > > > -- > John Sirois > 303-512-3301 > > > > > > > -- John Sirois 303-512-3301
