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.
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
